gulp babel and isparta #45

eddiemoore opened this Issue Jun 26, 2015 · 7 comments


None yet

5 participants


For some reason I can't use the normal ES6 imports with isparta in my gulpfile. If I use require it all works correctly, runs all my tests and covers all my code. But when I change over to use import I get:

$ gulp mocha
[14:54:55] Requiring external module babel/register
[14:54:56] Using gulpfile ~/Work/XXX/gulpfile.babel.js
[14:54:56] Starting 'istanbul'...

      throw er; // Unhandled 'error' event
Error: Unable to parse /Users/ed/Work/XXX/src/chat.js

Line 1: Unexpected reserved word


import gulp from 'gulp'
import istanbul from 'gulp-istanbul'
// import isparta from 'isparta' // Doesn't work
const isparta = require('isparta') // Works
import mocha from 'gulp-mocha'

gulp.task('istanbul', cb => {
      instrumenter: isparta.Instrumenter,
      includeUntested: true,
      babel: { stage: 0 }
    .on('finish', cb)

gulp.task('mocha', ['istanbul'], () => {
  return gulp.src('./test/**/*.js')
      reporter: 'spec'
      dir: './coverage',
      reportOpts: {dir: './coverage'},
      reporters: ['lcovonly']
pahund commented Jun 29, 2015

I have the same problem, anyone found a solution yet?

jedmao commented Jul 26, 2015

I can import isparta from 'isparta;` without issue; however, I'm getting the same error:

      throw er; // Unhandled 'error' event
Error: Unable to parse Z:\Documents\GitHub\postcss-link-colors\js\plugin.js

Line 1: Unexpected token

If it helps, I'm using a gulpfile.babe.js and my test task looks like this:

import gulp from 'gulp';
import isparta from 'isparta';
import istanbul from 'gulp-istanbul';
import mocha from 'gulp-mocha';
import plumber from 'gulp-plumber';

export default function test(done) {
            instrumenter: isparta.Instrumenter,
            includeUntested: true,
            babel: { stage: 0 }
        .on('finish', () => {
            gulp.src(['js/**/*.spec.js'], { read: false })
                    reporter: 'spec',
                    clearRequireCache: true
                    reporters: ['lcov']
                    thresholds: { global: 100 }
                .on('end', done);
@StefanoDalpiaz StefanoDalpiaz added a commit to StefanoDalpiaz/isparta that referenced this issue Aug 25, 2015
@StefanoDalpiaz StefanoDalpiaz Fix for issue #45: mixed ES6 and CommonJS export statements c73b56e

For anybody having this issue, I have found a solution for this.

Basically the problem originates from the fact that when you do import isparta from 'isparta';, the object that is returned is actually the original istanbul object, so the Instrumenter that you end up using is the original one, which does not understand ES6.

I have submitted a pull request to fix this problem.

In the meantime there is a nice workaround that you can use to make it work. Basically you have to import the instrumenter directly as an ES6 module, instead of using isparta.Instrumenter:

import { Instrumenter } from 'isparta';

    .pipe(istanbul({ instrumenter: Instrumenter }))
    // ...
jedmao commented Aug 25, 2015

@StefanoDalpiaz is the require statement somehow different? Perhaps that's why this works?:


Yes, requiring a module is different from importing it in ES6 style. Try having a look at the babel-transpiled version of import isparta from 'isparta';. I have created one for you here.

Basically what happens is that when you import it that way, first of all the isparta module is required as you would in CommonJS style, and then that required module is passed through a function that checks if it's an ES6 module: if it is, then the variable is left as is, if not, it is wrapped in an object like { 'default': module }. This is so that we can cater at the same time for CommonJS exports like module.exports = { ... }; and ES6 default exports like export default { ... };.

Now let's have a look at the source for isparta.js:

  • first it imports istanbul, which is not an ES6 module originally, so under the hood it is wrapped in an object { 'default': istanbul } (note that in newer version of babel the function that creates this object has been refined, and it no longer wraps the istanbul module, but still, though for different reasons, eventually the instrumenter doesn't get properly imported)
  • then all its properties are cycled and added in commonJS style to the exports. In this case the only property is default (which contains the actual istanbul module, as explained in the previous point), so that's the only thing imported so far
  • then the Instrumenter class and the version are exported in ES6 style, which under the hood just adds them normally to the exports object.
  • eventually then, the exported data looks like:
        'default': (original istanbul object),
        'Instrumenter': (isparta instrumenter),
        'version': (isparta version)

Let's keep in mind this data and go back to the initial transpiled version of import isparta from 'isparta'. This is what happens:

  • isparta is imported via require
  • the imported module is passed through the wrapping function, which recognises that it is an ES6 module and leaves it as it is - without wrapping it
  • the actual module that is used is what is stored in the default property of the imported object, which is the original istanbul module
  • so the Instrumenter property is read from the original istanbul instead of isparta, thus the instrumentation fails.

The reason why import('isparta').Instrumenter works is that by using normal requiring, the transpiled script will not use the 'default' property of the imported module, so it will all work as expected. You can see it for yourself here.

Hope this is clear.

jedmao commented Aug 26, 2015

Wow, @StefanoDalpiaz, thanks for the in-depth explanation! It's all perfectly clear now :)

@zckrs zckrs added a commit to zckrs/generator-yeoman-boilerplate-es6 that referenced this issue Oct 7, 2015
@zckrs zckrs Fix pre-test task
Cause bug in isparta
douglasduteil/isparta#45 (comment)
@jmeas jmeas referenced this issue in babel/generator-babel-boilerplate Oct 10, 2015

Coverage broken on master #238

@douglasduteil douglasduteil added a commit that closed this issue Oct 31, 2015
@douglasduteil fix: wrong export pattern
Closes #45

Alright Isparta is now exporting a Istanbul like structure
Closes #60

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment