Accommodate Babel 6 plugin API

[dzucconi]

Re: http://babeljs.io/blog/2015/10/29/6.0.0/#plugin-api

[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.

[elicwhite]

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.

[elicwhite]

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);
      }

[elicwhite]

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.

[elicwhite]

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

[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?

[elicwhite]

@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).

[elicwhite]

@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.

[elicwhite]

@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?

[elicwhite]

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

[elicwhite]

👍

[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]

@danawoodman thanks for providing the hin.

[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>
);

[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 👍 😄