Accommodate Babel 6 plugin API about babel-plugin-rewire

[speedskater]

@danawoodman thanks for providing the hin.

[valscion]

Hi @mmahalwy, could you create a separate issue for this? You can link back to this issue if you think that it would make sense. This issue is closed and I think it is easier to fix issues if they're separate.

EDIT: Oh, I see you've already done that in #110 — well, in that case, good job 👍 😄

[hydrotik]

I am assuming this is related to this error? 👍

Module build failed: TypeError: Plugin is not a function
[0]     at module.exports (/node_modules/babel-plugin-rewire/src/babel-plugin-rewire.js:26:9)

[rnicholus]

Correct. I'm creating a pull request as we speak.

[rnicholus]

After attempting to upgrade this plug-in to work w/ Babel 6, and failing due to other seemingly undocumented breaking changes in Babel's plug-in API, I have reversed course. Babel 6 is a bit of a mess at the moment, and it seems prudent to hold off upgrading to Babel 6 until the dust has settled and the library has stabilized a bit.

[TheSavior]

Can you document these things you came across for anyone else attempting to make the necessary changes to Babel-plugin-rewire? I was going to take a look myself.

[TheSavior]

I took a first stab at this by updating the things I know changed. You can see the diff here:

master...TheSavior:babel6

Currently getting:

Transformation failed: 
Error: unknown: Unexpected return value from visitor method function (path) {
        return fn.call(state, path, state);
      }

[TheSavior]

Relevant slack conversation log:

eliwhite [1:07 PM] 
Has something changed in babel’s expected return value from visitor functions?
Unexpected return value from visitor method function (path) {
        return fn.call(state, path, state);
      }

loganfsmyth [1:08 PM] 
@eliwhite: In 6.x, transform visitors don’t return anything (edited)

eliwhite [1:09 PM] 
@loganfsmyth: Interesting. Do you know of any reasonably complicated babel transform that has a git commit or PR with the necessary changes to go from babel 5 to babel 6 that I can look at and learn from?

loganfsmyth [1:10 PM] 
@eliwhite: Not sure, sorry. in this case you need to explicitly call `path.replaceWith( … )` to replace a node though

alxandr [1:10 PM] 
Big difference. ES6 transformers don't receive the node, they receive the path

[speedskater]

Thanks for Reportage this Bug and the Delay on this issue but I am currently on holidays and will return on the 23rd of november. I will then fix this bug and create a new beta.

[TheSavior]

In the mean time, I created a new babel plugin that doesn't have the full capability of this plugin, but at least solves our need:

https://github.com/TheSavior/babel-plugin-rewire-es5

It will only work for modules that use module.exports, and it very likely may fail for any variables that babel renames. These happen to not currently be concerns for us, so if they aren't concerns for you, feel free to give it a try.

[dcrockwell]

+1

[paprikka]

+1

[jrans]

+1

[doylem]

Having just tried to upgrade to Babel6, it seems this is the final blocker in getting it over the line. Rather than just +1'ing, I'm curious how I can help @speedskater ?

[rnicholus]

This was lost in the sea of annoying +1's, but speedskater said he would fix this after returning from vacation on the 23rd. And indeed there is a branch where work has started (and possibly almost finished). Thanks for all of your hard work @speedskater.

[speedskater]

@rnicholus thanks. As you have guessed I am right now working on babel 6.
@doylem Thank for your offer. Right now its just a lot of refactoring and it takes a bit of a time. But it would be great if you could help when its finished in testing it or by providing additional tests. By the time it will get stable again, I would really appreciate any help on oncoming issues :)

[speedskater]

There is a new beta version available now. 1.0.0-beta-2. Could you all please test it and if you have any issues with it could you please provide a PR with a minimal sample reproducing your error (analog to the samples in the repo used by https://github.com/speedskater/babel-plugin-rewire/blob/master/usage-tests/BabelRewirePluginUsageTest.js.

[wms]

@speedskater I just wanted to chime in and say thanks for getting a babel-6 compatible version of this library out so quickly. I've tried it in a rather small test-case and it appears to working well so far. Thanks!

[doylem]

@speedskater thanks so much ! I'll test with my app and get back to you.

[dzucconi]

I've upgraded and all is working well. Thank you.

[JoakimLofgren]

I can get my tests to run without isparta, but not with..

Anyone else experiencing that issue? (karma+webpack+isparta+rewire)

[torarnek]

It is possible to have this beta released on npm.org? (I am looking very much forward to babel 6 support, but is limited to pulling npms from npm.org)

[valscion]

@torarnek the beta is already released? I am myself using 1.0.0-beta-3 in my package.json and it works correctly. I think you can install the latest beta with npm install babel-plugin-rewire@next, and if the @next doesn't work, use the exact version number. As the plugin isn't yet out of beta, it won't be installed by just running npm install babel-plugin-rewire without specifying versions manually.

And, on another note, the beta3 version works flawlessly for me. Great job! I like the new API direction, too 👍

[doylem]

@speedskater a little delayed with other things, but in the end beta-3 worked great for me. Thanks again!

[speedskater]

@JoakimLofgren can you provide a concrete minimalistic example.
@torarnek it is only released as beta and has therefore to be specified explicitly. Thanks for @valscion for providing the detailed description. @warrenseymour @dzucconi @doylem thanks for testing and providing feedback.

[doylem]

@speedskater how long do you want to beta test for? Any idea when we might have a final v1.0.0 ?

[speedskater]

@doylem I will tackle the bugs occuring in the beta next monday and will than release a new beta. If this works out I will the final 1.0 with beginning of next year.

[elayman]

The beta doesn't seem to play well with babel-polyfill: https://babeljs.io/docs/usage/polyfill/

I get the following error:
Uncaught ReferenceError: get_ is not defined
at 'myWebpackEntryFile.js':2257:0 <- webpack:////babel-polyfill//core-js/modules/$.has.js:3:2

When I comment out the babel-polyfill, I get no uncaught reference, but then my babel isn't transpiling some of my ES6 features, and my tests fail.

Here are my settings:
//package.json

    "babel-core": "~6.3.13",
    "babel-loader": "~6.2.0",
    "babel-plugin-rewire": "1.0.0-beta-3",
    "babel-polyfill": "^6.3.14",
    "babel-preset-es2015": "^6.3.13",
    "babel-preset-stage-1": "^6.3.13",
    "webpack": "~1.10.1",
    "karma": "~0.12.31",
    "karma-chrome-launcher": "^0.1.7",
    "karma-coverage": "^0.3.1",
    "karma-jasmine": "~0.3.5",
    "karma-phantomjs-launcher": "~0.1.4",
    "karma-sourcemap-loader": "^0.3.4",
    "karma-spec-reporter": "~0.0.16",
    "karma-webpack": "~1.5.0"

//karma.config.js

module.exports = function(config, options) {
config.set({
    files: ['tst/entry.js'],
    frameworks: ['jasmine'],
    webpack: {
        module: {
            loaders: [
                { test: /\.js$/, exclude: 'node_modules', loader: 'babel-loader', query: { presets: ['es2015'] }
             ]
        },
        devtool: 'inline-source-map'
    },
    preprocessors: { 'tst/**/*.js': ['webpack', 'sourcemap'] }
    browsers: ['PhantomJS']
    reporters: ['spec'],
    port: 9876,
    plugins: [ require("karma-webpack"), require("karma-spec-reporter"), require("karma-jasmine"), require("karma-phantomjs-launcher"), require("karma-sourcemap-loader") ]
});

//tst/entry.js

//If I comment this out, I get no errors, but my code is not transpiled
require('babel-polyfill');
// load all specs into one bundle (any tests loaded here will fail to start because of the babel-polyfill above)
//https://github.com/webpack/karma-webpack/issues/23
const testsContext = require.context(".", true, /.spec.js$/);
testsContext.keys().forEach(testsContext);

Using "babel-plugin-rewire-es5": "^1.0.2", works btw.

[speedskater]

@elayman Thanks for reporting the issue. Could you please create a small sample? I will try to tackle your problem on monday before creating a new beta.

[dtothefp]

this plugin also doesn't play nice with https://www.npmjs.com/package/babel-plugin-add-module-exports. Babel 6 stopped supporting https://phabricator.babeljs.io/T2212 export default behavior for destructuring Objects in the import statement, i.e.

//something.js
export default {
  something: 'whateves'
}

//importer.js
import {something} from './something';  //undefined

instead

import allTheThings from './something';

const {something} = allTheThings;

or just export differently

//something.js
export const something = 'whatevs';

//we can leave this for "old times sake" if we want
export default {
  something
}

//importer.js
import {something} from './something';  //'whatevs'

if I try the config below or swap add-module-exports to be first item in the array ahead of rewire

"plugins": [
  "rewire",
  "add-module-exports",
  "transform-runtime",
  "transform-decorators-legacy",
  "typecheck",
  ["react-transform",
    {
    "transforms": [{
      "transform": "react-transform-hmr",
      "imports": ["react"],
      "locals": ["module"]
    }, {
      "transform": "react-transform-catch-errors",
      "imports": ["react", "redbox-react"]
    }]
  }]
]

So for the below example

//child-mock.js
export default {
  stuff() {
    return 'stuff';
  },
  things() {
    return 'things';
  }
};

//parent-mock.js
import child from './child-mock';

export default {
  callStuff() {
    return child.stuff();
  },
  callThings() {
    return child.things();
  }
};


//some-spec.js
import mock from '../mocks/parent-mock';

before(() => {
  mock.__Rewire__('child', {
    stuff() {
      return 'rewired stuff';
    },
    things() {
      return 'rewired things';
    }
  });
});

I get the error

✗ "before all" hook
        TypeError: _get__(...) is not a function
            at Context.<anonymous> 

I already reported here #80 but thought this may get more traffic on the Babel 6 issue thread. add-module-exports does not do very sophisticated checks for export default behavior and I'm assuming if @speedskater deems this a worthy issue it would be easier to be able to pass options to rewire of other supported plugins and it could polyfill this behavior, similar to how in my above .babelrc config there are options in an nested array (this used to go in the extra field in .bablerc but extra seems to no longer be supported. So mayb you would have

"plugins": [
  ["rewire",
    {
    "transforms": [{
      "transform": "add-module-exports"
    }]
  }]

I'm too up on creating Babel plugins but this seems to be how they accept options I'm guessing.

//package.json
    "babel-core": "^6.3.17",
    "babel-eslint": "^5.0.0-beta6",
    "babel-loader": "^6.2.0",
    "babel-plugin-add-module-exports": "^0.1.1",
    "babel-plugin-react-transform": "^2.0.0-beta1",
    "babel-plugin-rewire": "^1.0.0-beta-3",
    "babel-plugin-transform-decorators-legacy": "^1.2.0",
    "babel-plugin-transform-runtime": "^6.3.13",
    "babel-plugin-typecheck": "^3.5.1",
    "babel-polyfill": "^6.3.14",
    "babel-preset-es2015": "^6.1.18",
    "babel-preset-react": "^6.1.18",
    "babel-preset-stage-0": "^6.1.18",
    "babel-register": "^6.3.13",
    "babel-runtime": "^5.8.34",

[elayman]

@speedskater I have updated my comment with code snippets. Thanks.

[trodrigues]

Hi there!

I just tried this out on a couple of projects which use babel-polyfill, babel-register in development mode, and isparta for coverage.

Isparta gives me a No coverage information was collected, exit without writing coverage information but I wonder if this is more related to isparta + babel6 than with this plugin, as there's also someone complaining of issues without referring this plugin in this issue douglasduteil/isparta#104

[trodrigues]

After having these issues with isparta, I decided to go have a look at the current work on istanbul to enable usage with babel, and it seems like there's been some activity. They have an alpha version which works fine with babel, so I decided to give that a try.

However, while that works, when using it with babel-plugin-rewire, the coverage drops a lot.

I'm still not entirely sure if the problem is with babel-plugin-rewire or instanbul itself, and also not entirely sure how to investigate further.

I posted more details of the experience here gotwarlost/istanbul#212 (comment) also with a link to a fork of the istanbul demo project for babel https://github.com/trodrigues/sample-babel-node

I'll keep investigating and will post back if I find any more relevant information.

[elayman]

I got Istanbul working with Babel-plugin-rewire and Karma and webpack by making Istanbul run before Babel. I added Istanbul as a preloader and Babel + rewire plugin as a loader. Then the coverage doesn't worry about the injected rewire code.

On Jan 5, 2016, at 8:20 AM, Tiago Rodrigues [email protected] wrote:

After having these issues with isparta, I decided to go have a look at the current work on istanbul to enable usage with babel, and it seems like there's been some activity. They have an alpha version which works fine with babel, so I decided to give that a try.

However, while that works, when using it with babel-plugin-rewire, the coverage drops a lot.

I'm still not entirely sure if the problem is with babel-plugin-rewire or instanbul itself, and also not entirely sure how to investigate further.

I posted more details of the experience here gotwarlost/istanbul#212 (comment) also with a link to a fork of the istanbul demo project for babel https://github.com/trodrigues/sample-babel-node

I'll keep investigating and will post back if I find any more relevant information.

—
Reply to this email directly or view it on GitHub.

[dtothefp]

@trodrigues your explanation is not very useful for telling what the problem is, there are many interactions between Babel 6, Rewire, Isparta, and your test runner that could be causing your problem. I can confirm that Isparta works for me using Rewire, Karma, and Webpack.

Steps to make it work:

• make sure that you import/require all of the files that you want to run the Coverage report against, that includes your test code and all of your src code. In Webpack I use require.context
• make sure you do NOT double compile the files that will be processed by Isparta. I'm using Isparta in a Webpack preLoader, so it already compiles the es6 plus all of the Istanbul magic. You must also pass the same babelrc options to Isparta as you do to Babel

  const testCoverage = coverage && TEST;  //cli options and ENV config
  const coverageRe = /^.+?\/src\/js\/(config|services|modules|component-utils|module-utils)\/.+?\.jsx?$/;
  const excludeRe = /^.+\/node_modules\/(?!@hfa\/).+\.jsx?$/;

  //put isparta in preLoaders
  const isparta = {
    test: /\.jsx?$/,
    loader: 'isparta',
    exclude: /\/(test|node_modules)\//,
    include: coverageRe
  };

  //this is your Babel loader
    {
      test: /\.jsx?$/,
      exclude(fp) {
        let ex = false;

        if (testCoverage && !/\@hfa/.test(fp) && !/node_modules/.test(fp)) {
          ex = coverageRe.test(fp);
        } else {
          ex = excludeRe.test(fp);
        }

        return ex;
      },
      loader: 'babel',
      query: babelQuery
    }

  //here is the config that gets put on the webpack config object
  const coverageConfig = {
    isparta: {
      embedSource: true,
      noAutoWrap: true,
      babel: babelQuery
    }
  };

  //my babel config
  const babelrc = `{
    "presets": ["react", "es2015", "stage-0"],
    "env": {
      "development": {
        "plugins": [
          "rewire",
          "transform-runtime",
          "transform-decorators-legacy",
          "typecheck",
          ["react-transform",
            {
            "transforms": [{
              "transform": "react-transform-hmr",
              "imports": ["react"],
              "locals": ["module"]
            }, {
              "transform": "react-transform-catch-errors",
              "imports": ["react", "redbox-react"]
            }]
          }]
        ]
      },
      "production": {
        "plugins": [
          "transform-runtime",
          "transform-decorators-legacy",
          "typecheck"
        ]
      }
    }
  }`;

[speedskater]

@dtothefp thanks for your explanation.

[dtothefp]

@speedskater No problem figured I can save other people some time. Any chance you have any thoughts on the babel 6 module exports issue? #80

[trodrigues]

@dtothefp ah, sorry, I could've definitely explained that better.

So in my particular case I'm not using Karma or Webpack. I have some tests which are a simple JS file which node runs on the command line.

Previously, with babel 5, I was running it like this:
BABEL_ENV=test isparta cover test/runner

With the following .babelrc:

{
  "env": {
    "test": {
      "plugins": ["babel-plugin-rewire"]
    }
  }
}

It should be noted that test/runner was requiring the require hook, and that's how my babel code got transformed.

This worked.

After moving to Babel 6, the above stopped working. The tests still run, but I get this message from isparta: No coverage information was collected, exit without writing coverage information

Afterwards, I removed the require hook from test/runner and I changed the command to run the tests to the same that is mentioned on the isparta readme, so it would look like:
babel-node ./node_modules/isparta/bin/isparta cover test/runner

This shows the same message as before, about no coverage information being collected, and throws some additional errors about code transformation:

Transformation error; return original code
[TypeError: Cannot read property 'sections' of null]

At this point I decided to look at the istanbul alpha version with sourcemap support, which apparently works well with ES6, as demonstrated by the demo project they created.

So for that, I changed the command from before to babel-node ./node_modules/istanbul/lib/cli.js cover test/runner and the .babelrc (ignoring the env stuff for now) to:

{
  "presets": ["es2015"],
  "sourceMaps": "inline",
  "plugins": ["babel-plugin-rewire"]
}

This works. However, the coverage results I get are about half of what I get before this migration to Babel 6. I forked the sample project the istanbul maintainer created at https://github.com/trodrigues/sample-babel-node and attempted to add a module which is mocked with babel-plugin-rewire and seem to get similar results.

As you said, there's a lot of interactions here and it's a bit complicated to understand where the actual problem might be, if it's just my setup and configuration, or a bug in either this plugin or istanbul.

The original project where I was doing this is https://github.com/contentful/contentful-space-sync and I have a babel6 branch where I'm currently trying this out https://github.com/contentful/contentful-space-sync/tree/babel6

[trodrigues]

Ok, so I might've been worked up over nothing here. After having given up on this I decided to actually look at the generated HTML coverage and realized that the results isparta was giving me were based on the transpiled code and are very misleading. Some parts of the code that my tests never touch were being reported as covered.

What that means is that the results I am getting now with istanbul, over source maps and the actual source code are the real ones, and everything is actually working fine and there's no problem in babel-plugin-rewire at all.

Apologies for all the confusion I might've caused with this.

However, I can happily report that this is all using babel-plugin-rewire 1.0.0-beta3 and it works fine :)

[speedskater]

@trodrigues Thanks for reporting this. Could you please create a section in the readme documenting the integration with istanbul?

[dtothefp]

@speedskater unfortunately 😢 some craziness has been going on with Babel 6 again, looks like. 6.4 had some breaking changes for class properties. Not sure if what has happened in 6.4 is the issue but 1.0.0-beta-4 definitely is breaking for me, maybe related to the new peerDep babel-plugin-syntax-jsx

https://phabricator.babeljs.io/rBCd2f5a409daa0d2dcd6cff44d07aaac5d7a0d24b8

ERROR in ./src/js/components/login-form/index.jsx
Module build failed: TypeError: /Users/davidfox-powell/dev/donate-frontend/src/js/components/login-form/index.jsx: Property children[0] of JSXElement expected node to be of a type ["StringLiteral","JSXExpressionContainer","JSXElement"] but instead got "JSXText"
    at validate (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-types/lib/definitions/index.js:101:13)
    at validator (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-types/lib/definitions/index.js:49:7)
    at Object.validate (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-types/lib/definitions/index.js:182:10)
    at validate (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-types/lib/index.js:268:9)
    at Object.builder (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-types/lib/index.js:221:7)
    at RewireState.JSXElement (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-plugin-rewire/lib/babel-plugin-rewire.js:52:54)
    at NodePath._call (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:74:18)
    at NodePath.call (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:46:17)
    at NodePath.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:104:12)
    at TraversalContext.visitQueue (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:153:16)
    at TraversalContext.visitMultiple (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:108:17)
    at TraversalContext.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:195:19)
    at Function.traverse.node (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/index.js:139:17)
    at NodePath.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:114:22)
    at TraversalContext.visitQueue (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:153:16)
    at TraversalContext.visitMultiple (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:108:17)
    at TraversalContext.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:195:19)
    at Function.traverse.node (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/index.js:139:17)
    at NodePath.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:114:22)
    at TraversalContext.visitQueue (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:153:16)
    at TraversalContext.visitMultiple (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:108:17)
    at TraversalContext.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:195:19)
    at Function.traverse.node (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/index.js:139:17)
 @ ./test/integration/components/login-form-spec.js 48:17-49

ERROR in ./src/js/components/third-step/index.jsx
Module build failed: TypeError: /Users/davidfox-powell/dev/donate-frontend/src/js/components/third-step/index.jsx: Property body[1] of BlockStatement expected node to be of a type ["Statement"] but instead got "JSXElement"
    at validate (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/node_modules/babel-types/lib/definitions/index.js:101:13)
    at validator (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/node_modules/babel-types/lib/definitions/index.js:49:7)
    at Object.validate (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/node_modules/babel-types/lib/definitions/index.js:182:10)
    at validate (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/node_modules/babel-types/lib/index.js:268:9)
    at Object.builder (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/node_modules/babel-types/lib/index.js:221:7)
    at NodePath.replaceExpressionWithStatements (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/replacement.js:238:54)
    at NodePath.insertBefore (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/modification.js:51:10)
    at RewireState.JSXElement (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-plugin-rewire/lib/babel-plugin-rewire.js:47:21)
    at NodePath._call (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:74:18)
    at NodePath.call (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:46:17)
    at NodePath.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:104:12)
    at TraversalContext.visitQueue (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:153:16)
    at TraversalContext.visitSingle (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:113:19)
    at TraversalContext.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:197:19)
    at Function.traverse.node (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/index.js:139:17)
    at NodePath.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:114:22)
    at TraversalContext.visitQueue (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:153:16)
    at TraversalContext.visitMultiple (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:108:17)
    at TraversalContext.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:195:19)
    at Function.traverse.node (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/index.js:139:17)
    at NodePath.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:114:22)
    at TraversalContext.visitQueue (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:153:16)
 @ ./test/integration/components/quick-card-spec.js 56:17-49

ERROR in ./src/js/components/quick-card/index.jsx
Module build failed: TypeError: /Users/davidfox-powell/dev/donate-frontend/src/js/components/quick-card/index.jsx: Property body[1] of BlockStatement expected node to be of a type ["Statement"] but instead got "JSXElement"
    at validate (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/node_modules/babel-types/lib/definitions/index.js:101:13)
    at validator (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/node_modules/babel-types/lib/definitions/index.js:49:7)
    at Object.validate (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/node_modules/babel-types/lib/definitions/index.js:182:10)
    at validate (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/node_modules/babel-types/lib/index.js:268:9)
    at Object.builder (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/node_modules/babel-types/lib/index.js:221:7)
    at NodePath.replaceExpressionWithStatements (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/replacement.js:238:54)
    at NodePath.insertBefore (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/modification.js:51:10)
    at RewireState.JSXElement (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-plugin-rewire/lib/babel-plugin-rewire.js:47:21)
    at NodePath._call (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:74:18)
    at NodePath.call (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:46:17)
    at NodePath.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:104:12)
    at TraversalContext.visitQueue (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:153:16)
    at TraversalContext.visitSingle (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:113:19)
    at TraversalContext.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:197:19)
    at Function.traverse.node (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/index.js:139:17)
    at NodePath.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:114:22)
    at TraversalContext.visitQueue (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:153:16)
    at TraversalContext.visitMultiple (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:108:17)
    at TraversalContext.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:195:19)
    at Function.traverse.node (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/index.js:139:17)
    at NodePath.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:114:22)
    at TraversalContext.visitQueue (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:153:16)
 @ ./test/integration/components/quick-card-spec.js 60:17-49

ERROR in ./~/@hfa/form-components/lib/components/higher-order-input/index.jsx
Module build failed: TypeError: /Users/davidfox-powell/dev/donate-frontend/node_modules/@hfa/form-components/lib/components/higher-order-input/index.jsx: Property children[0] of JSXElement expected node to be of a type ["StringLiteral","JSXExpressionContainer","JSXElement"] but instead got "JSXText"
    at validate (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-types/lib/definitions/index.js:101:13)
    at validator (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-types/lib/definitions/index.js:49:7)
    at Object.validate (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-types/lib/definitions/index.js:182:10)
    at validate (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-types/lib/index.js:268:9)
    at Object.builder (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-types/lib/index.js:221:7)
    at RewireState.JSXElement (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-plugin-rewire/lib/babel-plugin-rewire.js:52:54)
    at NodePath._call (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:74:18)
    at NodePath.call (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:46:17)
    at NodePath.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:104:12)
    at TraversalContext.visitQueue (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:153:16)
    at TraversalContext.visitSingle (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:113:19)
    at TraversalContext.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:197:19)
    at Function.traverse.node (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/index.js:139:17)
    at NodePath.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:114:22)
    at TraversalContext.visitQueue (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:153:16)
    at TraversalContext.visitSingle (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:113:19)
    at TraversalContext.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:197:19)
    at Function.traverse.node (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/index.js:139:17)
    at NodePath.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/path/context.js:114:22)
    at TraversalContext.visitQueue (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:153:16)
    at TraversalContext.visitMultiple (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:108:17)
    at TraversalContext.visit (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/context.js:195:19)
    at Function.traverse.node (/Users/davidfox-powell/dev/donate-frontend/node_modules/babel-traverse/lib/index.js:139:17)

[valscion]

Maybe the default caret versioning of peerDependency babel packages is too wide a version range for this plugin..? Seems like even semver minor version upgrades have the possibility to cause breaking changes, causing bugs like these to crop up 😣.

@dtothefp can you try a version of babel-plugin-rewire with the peerDependencies changed to 6.3.x version instead of e.g. "babel-plugin-syntax-jsx": "^6.3.13"?

EDIT: Oh well, that would also blow up your upgrade to babel 6.4, I'm afraid, so it does no good. Sorry 😅

[speedskater]

@dtothefp, @valscion it wasn't an issue with babel. I think it was a regression of my initial attempt to fix #82 (sorry ;) ). I think it is fixed now. Will release a new beta 5 later today. So please keep a look at the gitter channel for the update.

[dtothefp]

@speedskater fixed my issue, thanks

[srph]

Hey, I'm trying out v1.0.0-beta-5 now. I haven't encountered any errors yet. Great work by the way, @speedskater.

I wonder why this issue isn't closed yet?

[rnicholus]

Beta5 seems to be gold. I'm ready for this to be a 1.1.0 release on my end.

[speedskater]

@rnicholus. @srph. @dtothefp Thanks for your feedback. As some further issues have occured. I will have a look at the project on next wednesday or thursday and will try to ship one more beta. If no more show stopping bugs occur then i will switch to an rc-1 without a beta flag to get more feedback.

[kiaking]

Is it correct that without this fix we can't use babel-plugin-rewire with Babel 6 or do we have any workaround?

[srph]

What do you mean? The latest version (beta) works great

[kiaking]

@srph Oh I see. I'll use beta then. Thanks.

[danosaure]

I'm not too sure how to use this plugin. I would like to not to have to add it in my .babelrc because I only want to use it for my tests (not part of prod install). Can someone help me out and show me where to define that plugin with the following command line:

./node_modules/.bin/babel-node 
    node_modules/.bin/babel-istanbul cover --config=istanbul.json --dir coverage/unit
    node_modules/.bin/_mocha -- 'src/**/*.spec.unit.js'

(multi-line for easier reading. It's all on one line)

For the curious, after 2 weeks of fooling around, this is the best I can come up with to be able to have coverage report on the es6 code itself, and not the transpiled code.

I have tried to put the "babel-node --plugins rewire", but it doesn't work.

[trodrigues]

@danosaure if that doesn't work, you can try with the full name, such as babel-node --plugins babel-plugin-rewire.

In any case, you can have it in your .babelrc if you follow the example here.

This is is for instance how one of my configs looks like:

{
  "presets": [
    "es2015"
  ],
  "plugins": [
    "transform-runtime",
    "transform-flow-strip-types"
  ],
  "env": {
    "test": {
      "sourceMaps": "inline",
      "plugins": ["babel-plugin-rewire"]
    }
  }
}

and then you just run BABEL_ENV=test babel-node ./node_modules/istanbul/lib/cli.js cover path/to/tests

[jayasurian123]

I am using beta 5 but i have the same problem now also.
this is my webpack config

module: {
  loaders: [
    {
      test: /\.js$/,
      loader: 'babel',
      include: [sourceDir, assetsDir],
      query: {
        presets: ['react', 'es2015'],
        plugins: ["babel-plugin-rewire"]
      },
      exclude: nodeDir
    },
  ]
}

I have moved the config to .babelrc also. But no luck. I am not sure i m configuring it wrongly or the packages have problem!

Property children[0] of JSXElement expected node to be of a type ["StringLiteral","JSXExpressionContainer","JSXElement"] but instead got "JSXText"

Once i have removed this code it would compile.

render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.querySelector('[data-main]')
);

i am really confused!

[ajbradley]

Hi All - trying to integrate this plugin with Mocha tests and running into Temporal Dead Zone issues in the generated code.
Running on Linux/Ubuntu with node 4.2.6, Babel 6, and a .babelrc containing:

{
    "presets": ["es2015-node4"],
    "plugins": [],
    "env": {
        "test": {
            "sourceMaps": "inline",
            "plugins": ["babel-plugin-rewire"]
        }
    }
}

The code causing the problem is:

import chai  from 'chai';
var expect = chai.expect; // use the "expect" style of Chai

When looking at the generated code, the get_ is called, before the RewiredData_ is declared:

'use strict';

Object.defineProperty(exports, "__esModule", {
  value: true
});
exports.__RewireAPI__ = exports.__ResetDependency__ = exports.__set__ = exports.__Rewire__ = exports.__GetDependency__ = exports.__get__ = undefined;

var _chai = require('chai');

var _chai2 = _interopRequireDefault(_chai);

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

var expect = _get__('chai').expect; // use the "expect" style of Chai
let _RewiredData__ = {};

function _get__(variableName) {
  return _RewiredData__ === undefined || _RewiredData__[variableName] === undefined ? _get_original__(variableName) : _RewiredData__[variableName];
}
...

This generates a runtime error:

> mocha --compilers js:babel-register

.../test/test.js:15
  return _RewiredData__ === undefined || _RewiredData__[variableName] === undefined ? _get_original__(variableName) : _RewiredData__[variableName];
         ^

ReferenceError: _RewiredData__ is not defined

While the get_() function is declared below the 'let', the rules of 'let' scoping means that get_() cannot be referenced before RewiredData_ is declared ( as outlined here).

Do you think I have something misconfigured?

I haven't looked into the code to see if this is feasible but changing the 'let' declaration to a 'var', or moving the declaration of RewireData_ to the top of the file, could both fix this

[srph]

@ajbradley - That's weird, here check this Babel Playground.

Edit: Oops, my bad. I misunderstood.

First, can anyone make a repository of their issue? Well, it's pretty hard to reproduce the same setup.

Also, @jayasurian123: Not sure if I understand well. You're supposed to use the plugin in a test environment, not in the actual web application.

{
  "presets": ["es2015", "stage-0", "react"],
  "plugins": ["transform-inline-environment-variables"],
  "env": {
    "test": {
      "plugins": ["rewire"]
    }
  }
}

[ajbradley]

You can find a demo repo that illustrates the TDZ errors at ajbradley/babel-plugin-rewire-issue71

[speedskater]

@srph thanks for answering the question.

@ajbradley thanks for providing the sample code. I will have a look at the TDZ issues asap (I think replacing the lets with vars should fix this issue) but I think it will take me about a week to get to fix this issue.

[srph]

@ajbradley
Oh, I see. For the meantime (and I think you should), use the import destructure syntax.

import {expect} from 'chai';

@speedskater
A week? Is there any issue? If not, I can take a look if there's anything I can do ;).

[speedskater]

@srph that would be great. No there is no specific issue about it. Its only because of my (a bit tight ;) ) schedule.

[GulinSS]

@ajbradley as a quick workaround add transform-es2015-block-scoping to your plugin list in .babelrc.

[ajbradley]

@speedskater @GulinSS Thanks for the response - my concern about this approach (the solution of changing 'let' to 'var') is that the initialisation for the export is not hoisted along with the declaration. i.e.

if ((typeOfOriginalExport === 'object' || typeOfOriginalExport === 'function') && Object.isExtensible(getLog)) {
    addNonEnumerableProperty('__get__', _get__);
    addNonEnumerableProperty('__GetDependency__', _get__);
    addNonEnumerableProperty('__Rewire__', _set__);
    addNonEnumerableProperty('__set__', _set__);
    addNonEnumerableProperty('__reset__', _reset__);
    addNonEnumerableProperty('__ResetDependency__', _reset__);
    addNonEnumerableProperty('__with__', _with__);
    addNonEnumerableProperty('__RewireAPI__', _RewireAPI__);
}
... // Removed a lot of template code here for clarity
var _RewireAPI__ = {};

Here, while the declaration is hoisted to the top of the scope, AFAIK the initialisation remains at the end. This means that the line:

    addNonEnumerableProperty('__RewireAPI__', _RewireAPI__);

is the same as:

    addNonEnumerableProperty('__RewireAPI__', undefined);

I had changed the templates, adding at the beginning of each:

var _RewireAPI__; if ( _RewireAPI__ === undefined) _RewireAPI__ = {};

which ensures that only a single initialised value is assigned to the var. I had added this to the start of both the universalAccessorsTemplate and enrichExportTemplate (I'm sorry I don't have my actual workaround here - on a different machine) but I think it worked...

[speedskater]

@ajbradley I think you are right. My currently suggested approach is to change the API to a single exported api object, without nonenumerable exports and modifying the default export. (please see https://gitter.im/speedskater/babel-plugin-rewire). To remove the burden to switch to the new API, I am currently preparing a codemod, which should transfer existing code to the new API.

In this case switching to the var version should not cause further issues. Furthermore, statements like addNonEnumerableProperty will not be needed in the future. Regarding your concern of double assignment, the variablename RewiredData_ is generated in a unqiue way (hence, it will not be assigned twice).
Therefore accessing the the uninitialized value of RewiredData_ in the get method should not be a problem.
Or do you think, we still need to integrate a function like this to make sure the hoisted RewiredData will work in all cases

function __getRewireAPI() { 
if(_RewiredData__ === undefined) {
   _RewiredData__ = {}
} 
return _RewiredData__;

What are your opinions on this approach?

[speedskater]

Hi all.
I am currently stuck in providing a decent solution, which using babel only can generate a rewireing API which works for code containing wildcard exports or reexporting default exports. The problem is, that I have found no way, to uniquely identify another source modul without using and additional export.
Does anybody have an idea, how a module system independent solution could look like which uniquely identifies a module without adding an additional export or need to specify absolut paths?

[trodrigues]

I'm not sure I entirely understand the problem (more specifically the part about reexporting default exports).

In any case, I think I would be fine with specifying absolute paths, and I think it makes the code more obvious to look at and less magical (as in, you're never wondering if it's guessing stuff and if there could be some name collision somewhere).

I recently had to write a test where I had to use the RewireAPI object, and I wasn't yet aware of these particular situations because I had only been mostly rewiring dependencies which had default exports. I find that the code that one ends up with when using this API is not as obvious to understand.

I'd be totally fine with doing something like moduleToBeTested.__Rewire__('./path/to/module', 'exportTarget, stub).

But that's just my personal opinion, as I said, I might be misunderstanding the situation you're referring to :)

[speedskater]

@trodrigues Thanks for your feedback. I think I might need to explain the problem a bit more detailed.

In an ideal world it would be perfect to write something like this:

rewire('path/to/module/').set('exportTarget', stub);

The Problem is that somehow we need to access the rewireapi for the path 'path/to/module'. Until now we patched the api on the default export of the module specified in 'path/to/module' and furthermore added a named export.

So far so good, this worked in most cases but trouble startes in the following three use cases.

• A primitive or constant or frozen javascript object is added as a default export -> not possible to add the api to this object
• Reexporting of named / default exports. Assume you have a module a importing modules b and c

//Both exports in this case provide the rewire api and hence will result in a name clash.
export * from 'path/to/module/b'
export * from 'path/to/module/c'

• Wildcard Imports

import * from 'path/to/myredux/reducers';

In this case the imported reducers might be polluted with the additional rewire api named import or an additional default export.

Unless we find a solution to export the "ModuleAPI" without polluting the current module interface we are stuck, because we cannot not know in which way a code which is instructed by the plugin will be used.

What makes matters worse is that we cannot change the generated api to use some kind of ioc paradigm. Namely, let each module register its api.
Although this seems like the cleanest approach we might not know what the location of a module is, as the source of a module might be provided by its source code only.

@trodrigues Does this make the problem clearer?

[TheSavior]

@speedskater Thank you for laying out the problem so clearly.

From my experience working on the other rewire packages, there were two points to the philosophy that I want to mention.

1. Since the user is Rewiring in test, the user is typically only rewiring their own modules.
2. Don't fail on other modules.

So to your point about being unable to rewire a primitive, constant, or frozen javascript object: I don't think this is a big problem. If the user knows they want to rewire it, they can easily write their module in a way that enables rewire to work. In all cases with the other rewire packages, the end user has understood and worked with this limitation without complaint.

Reexporting of named/default exports: I think if your module only does:

export * from 'path/to/module/b'

That should work because we can detect that we are already exporting the rewire api, and that it is already attached to the default export. The real interesting hard case is with the double export * you have:

export * from 'path/to/module/b'
export * from 'path/to/module/c'

I think this case falls into the above philosophies. If a user wants to rewire something, they need to know this is a limitation and should write things differently to support it. The real challenge here is getting it to not break when it is deeper in node_modules or some external package. Rewire should never break when just running on code.

The importing of all reducers is interesting as well. It seems similar to the problem of exporting enumerable properties.

@speedskater Do you feel like these problems could be solvable, while less than ideal, if we stated that a limitation of the module was wildcard imports / exports and modules with wildcard imports / exports were not rewire-able?

[speedskater]

@TheSavior Thank you for your extensive feedback.

You are definitely right that all boils down to the case (which is

export * from 'path/to/module/b'
export * from 'path/to/module/c'

as "import *" cases could be worked around.

I like your point about users only rewire modules of their own and maybe we should look at the problem from different angle. What if we specify /* @moduleId=/mySpecial/ModuleId/String */
at the top of source files we want to rewire (the comment will be stripped out in production builds anyway) and in test files we can say getModule('/mySpecial/ModuleId/String').set ...
What do you think about this idea?

In cases where we have information about the source location on the files system or information about module ids from the modulesystem itself, we could even automatically infer this information.

Another problem we should consider is module systems which are different from commonjs like systemjs (which is actually causing a bug as well #93 (comment)), or maybe webpacks 2 new es6 modules (http://www.2ality.com/2015/12/webpack-tree-shaking.html) or upcomming browser implementations. So I think we shouldn't rely on any behaviour of an existing module system (or even run our samples with different module systems).

[TheSavior]

@speedskater

In general, ES2015 duplicate wildcard exports with conflicts shouldn't throw, right? I believe the last one wins, but doesn't throw due to a conflict. So what that would mean is that the rewire export might not be what you expect, but it should at least not throw, right?

My understanding is that the only goal of your approach with the comments it to whitelist the modules to add the rewire API to instead of rewiring every module. If we can do a better job of not adding the rewire api, and just not failing on modules, I'd prefer to keep it low cost to use by not requiring a comment at the top of each file.

In regards to the other module systems, I think we should definitely have tests for whatever we support. I'm not familiar with SystemJS in particular, but I don't think webpack tree shaking is a problem for us since I think it would only be a possible problem when using like karma-webpack or something but in test, the export would be used and thus not tree shaken out.

[speedskater]

@TheSavior Regarding es2015 duplicate exports as far as i have tested this is not the case. The last one does not win, but it results in an error.

the idea of the comment is to generate code like the following

RewireSupport.registerModuleAPI('myModuleIdentifierExtractedFromTheComment', RewireAPI);

in the actual test you can than lookup the module api by its id without the need to provide an additional export or changing the default export.

[TheSavior]

@speedskater I don't have the context that you have, so perhaps it is worthwhile to take a step back first.

The topic of this issue is purely to work with babel 6. My understanding is that it is not a goal of the ticket to request additional features or capabilities, but to simply work with babel 6.

Was there anything inherently different about babel 6 that is keeping us from having the same capabilities as before and just releasing a version that would at least run with babel 6 and not fail in new ways from that which worked with babel 5?

If this pain we've started having is purely due to trying to support new es2015 features, perhaps we should separate these two discussions and first get out a new release for people to use as they were, and then figure out these things separately. It would likely require two major version bumps instead of doing it all at once, but this ticket was opened 3 months ago, so perhaps it is worth it.

That might also help us understand better what actual changes occurred outside of supporting babel 6's api that is making this break and considering a totally different API layer.

[speedskater]

@TheSavior I think you are right, that it would make sense to have a new intermediate babel 6 version out there to remove the pressure of finding a new approach.
In this case I would say, I will fix the jsx switch issue first, will than close this issue and create a new version which will be a non beta version. Furthermore we will create new issue where we will discuss the remaining issues to be es2015 compliant.
Regarding the version numbering I would prefer to stay below 1.0.0 and switch to correct version numbering as soon as we have found a way to tackle the remaining issues.

What do you think?

[TheSavior]

That all sounds great to me.

Re version numbers, I don't particularly care. Version numbers don't really mean anything as long as we follow semver. I don't see any particular reason to stay below 1.0.0 and just bump to 2.0.0 if we have to change the API and can't resolve things without breaking compatibility.

[speedskater]

@TheSavior sounds fine for me too. But maybe we should start to deprecate api like Rewire and GetDependency instead of the more familiar get, set

[TheSavior]

👍

[danawoodman]

For prosperity's sake, I was getting the same error @dtothefp was getting (eg TypeError: _get__(...) is not a function) and the issue was that I had a require('...') statement for a file that exported default:

File mylib.js:

export default () => { }

File somethingelse.js:

const mylib = require('./mylib')
//...

Threw an error. The resolution was simple, either:

• Change require('./mylib') to require('./mylib').default
• Change to import mylib from './mylib'

Since I had migrated from Babel 5 to Babel 6 a lot of my imports used require without explicitly importing the default export.

Not sure that's related to the core issue of this thread but this was the only search result relevant to the above issue. Hope it helps someone.

[speedskater]

@ajbradley, @srph To be able to finally publish a working babel 6 version. I reconsidered the tdz issues and replaced RewiredData by a var declaration and moved the declaration of the RewireAPI at the beginning of the generated code. I hope that this fixes all tdz issues.

[speedskater]

It took longer as expected but we finally pushed 1.0.0.-rc-1 as a default version to the npm repository.
Hence, I will close this issue.

[atticoos]

@speedskater is there a PR or commit you could reference to that addressed this? 😄

[trainerbill]

I am using rc1 and getting a plugin error via gulp-babel:

TypeError in plugin 'gulp-babel'
Message:
Filename must be a string

works fine if i just remove the rewire from .babelrc

[mmahalwy]

I keep getting this error:

Module build failed: TypeError: /Users/mmahalwy/Sites/sparrow/src/routes.js: Cannot read property 'node' of null
    at RewireState.JSXElement (/Users/mmahalwy/Sites/sparrow/node_modules/babel-plugin-rewire/lib/babel-plugin-rewire.js:49:47)
    at NodePath._call (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/path/context.js:63:18)
    at NodePath.call (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/path/context.js:47:17)
    at NodePath.visit (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/path/context.js:93:12)
    at TraversalContext.visitQueue (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/context.js:146:16)
    at TraversalContext.visitMultiple (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/context.js:110:17)
    at TraversalContext.visit (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/context.js:176:19)
    at Function.traverse.node (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/index.js:135:17)
    at NodePath.visit (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/path/context.js:103:22)
    at TraversalContext.visitQueue (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/context.js:146:16)
    at TraversalContext.visitQueue (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/context.js:152:21)
    at TraversalContext.visitSingle (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/context.js:115:19)
    at TraversalContext.visit (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/context.js:178:19)
    at Function.traverse.node (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/index.js:135:17)
    at NodePath.visit (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/path/context.js:103:22)
    at TraversalContext.visitQueue (/Users/mmahalwy/Sites/sparrow/node_modules/babel-traverse/lib/context.js:146:16)
 @ ./src/containers/Region/spec.js 17:14-31

and the file is:

export default () => (
  <Route path="/" component={App}>
    <IndexRoute component={Home} />
  </Route>
);