Closed ryan-roemer closed 8 years ago
Without digging into it, it seems that this would involve:
AssignmentExpression
s and VariableDeclarator
s whose value is set by a call to __webpack_require__
, and generate a map of identifier-to-webpack-module.CallExpressions
with a callee of _interopRequireDefault
(we assume the Babel transform won't change the name of this function)._interopRequireDefault
CallExpression
is detected in the context of an AssignmentExpression
or VariableDeclarator
, consult identifier-to-webpack-module map to determine which module is indirectly referenced. When identified, add this new identifier to the identifier-to-webpack-module map.It may also be possible to recursively examine scope when certain conditions are met, but this seems like it would perform poorly.
That should solve the case you've outlined above. However, it would not account for destructured imports/exports, which is probably equally likely to occur, and which could add significant complexity. I can't remember how Babel transpiles those references - it may be moduleName.exportName
which seems doable at first glance.
Keep in mind that adding a second parse-and-traverse step will worsen performance. If you can detect as part of the same parse-and-traverse, that would be ideal. However, if that's not an option, you may be able to at least cache that AST to avoid the second (or third) parse.
@divmain -- Maybe we just simplify the problem space to a heuristic of detecting just this instead:
exports.Provider = _Provider2["default"];
exports.connect = _connect2["default"];
OR
exports.Provider = _Provider2.default;
exports.connect = _connect2.default;
So basically:
exports.Foo = Foo.default;
exports.Bar = Bar["default"];
How much effort would that take?
That would be much easier, so long as
If that's the case, I can't imagine it would take more than a couple of hours. The last issue should be mitigable if you track the source variables (_Provider2
and _connect2
in your example), given a bit more time.
One other thing to note is that I'm unsure of the stability of the ES6-require interop code. Its definitely not an externally-facing API, so there's the risk of this silently breaking on you down the line.
Released in inspectpack@0.4.1
of this form:
Task:
Add a new
MULTIPLE_EXPORTS_ES
key with parse to detect this common form./cc @divmain