TypeError on named re-exports

[spncrlkt]

I'm using babel-plugin-rewire, and really like it! I ran into the following blocking issue.

If I do a named re-export like:

export * as core from './core.js';

I get the following error:
"TypeError: (...)/dev/rewire-example/exports.js: Cannot read property 'name' of undefined"

---

Possible solution:
when i change the following line in the installed node_module, the error goes away. Seems like on re-exports, specifier.local doesn't exist, but specifier.exported does exist. I'm not sure if this would break anything, so want to get a quick sanity check.

// lib/babel-plugin-rewire.js:100-102
var hasDefaultExport = specifiers.some(function (specifier) {
- return specifier.local.name === 'default';
+ return specifier.exported.name === 'default';
});

https://github.com/speedskater/babel-plugin-rewire/blob/master/src/babel-plugin-rewire.js#L121

Repro repo: https://github.com/spncrlkt/babel-plugin-rewire-repro

---

Update:
Seems like the case I'm trying to handle would be similar to a wildcardExport. The difference is it's a namedWildcardExport. I'm going to write a failing case for it, then begin looking at a fix.

---

Update: this is a stage-1 export option, which is proposed here: https://github.com/leebyron/ecmascript-more-export-from. Does babel-plugin-rewire want to work w/ babel's stage-1 preset?

Thanks!

[speedskater]

@spncrlkt I would prefer not to work with stage-1 export. What do you think about the solution proposed in https://gitter.im/speedskater/babel-plugin-rewire do only work with a sinlge named export containing all the API and a codemod transferring the existing code to it?

[elicwhite]

A named export would imply a different API than rewire itself, unless you still Object.defineProperty() to the default export. It is imperative to not break compatibility with the API rewire provides because there are many modules that are built on top of it, such as [privatestate]https://github.com/wealthfront/privatestate] which depend on the shared API of rewire, rewire-webpack, rewiriefy, rewire-global, and the current version of babel-plugin-rewire.

[speedskater]

@TheSavior thats true. But in my optionion the main focus of this project should be to provide the best mocking functionality for es6 code, regardless of the used module implementation. The named export module/api object will iteslf be API-compatibel with rewire. Hence to provide backward compatibility it is simply a matter of reexporting this object as the default export and batch it on the default export. This can be done by another plugin, or can also be done by a plugin, which uses the old commonjs default export behavior.
What is the main benefit, on batching the api on the default export, beside getting into troubles for not expandable or constant objects, primitive values, reexported defaults, and many more?

[spncrlkt]

@speedskater Provided babel-plugin-rewire can accommodate my code under test (containing named wildcard exports, as above), I have no opinion on what the rewire API looks like. Whatever you think is best. I just want to use stage-1 exports.

Thank you for all your hard work!

[speedskater]

@TheSavior, @spncrlkt The problem regarding reexports and the rewire plugin approach itself is more severe as I have initially thought.
If you have any idea on how we can progress (keeping in mind that the approach must work regardless of the module system) please participate in the discussion on how we can come to a general es6 solution: https://gitter.im/speedskater/babel-plugin-rewire or here #71 (comment)

[tomatau]

👍 hoping a good solution can be found soon!

[speedskater]

@spncrlkt I have merged your fix into the master branch. Thanks for your PR. I think we will still have to find a way how to proceed without polluting existing named exports but it will be a task for the upcoming releases.