Closed dmail closed 2 years ago
I assumed @rollup/plugin-commonjs
was responsible of handling named exports but it seems to be in the scope of other tools like cjs-module-lexer
I just discovered esinstall. It is marvelous. They are doing a mix of static analysis + runtime analysis. Link to the code where they combine @rollup/plugin-commonjs
with cjs-module-lexer
:
Unfortunately I cannot reuse esinstall
because my use case is different but I can borrow the concepts.
Hey folks. This issue hasn't received any traction for 60 days, so we're going to close this for housekeeping. If this is still an ongoing issue, please do consider contributing a Pull Request to resolve it. Further discussion is always welcome even with the issue closed. If anything actionable is posted in the comments, we'll consider reopening it. ⓘ
@dmail it might be useful to you: I have just published rollup-plugin-commonjs-named-exports which takes the cjs-module-lexer approach at exporting named re-exports.
Nice one. I keep wondering if we should not add cjs-module-lexer to the commonjs plugin itself but cannot seem to find time for it as it would not be 100% trivial.
On my side I took the time to create something inspired from esinstall that is using cjs-module-lexer + many other rollup plugins to convert commonjs to esm. It works like a charm until now but it's not open source as it contains some specificities.
Some of my dependencies are using commonjs re-exporting exports from an other file
main.cjs:
helper.cjs:
When using
@rollup/plugin-commonjs
to convert these files to esm, the named exports are lost. It practiceanswer
isundefined
in the following code where./dist/main.cjs
is generated by rollup.Expected Behavior
@rollup/plugin-commonjs
generate code re-exporting the named exports.Actual Behavior
@rollup/plugin-commonjs
is writing all named exports on a default exportAdditional Information
This issue replicates a pattern used by packages like react or react-is.