-
-
Notifications
You must be signed in to change notification settings - Fork 573
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(commonjs): avoid wrapping commonjsRegister
call in createCommonjsModule(...)
#602
Conversation
d7142be
to
c7fb33c
Compare
@shellscape @lukastaegert |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately I do not think we can keep it this way, see my comment. The resulting code would only work for cjs
targets, and I am not sure there is a simple fix for other targets that does not involve adding exceptions everywhere. My feeling is that for now, we would be happier with keeping the wrapping in this case. Also note that larger changes here will present terrible merge conflicts with #537 once this moves forward again (I actually consider picking this up myself as it might have a huge impact).
})] | ||
}); | ||
|
||
const code = await getCodeFromBundle(bundle, { exports: 'named' }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you run this test but add a parameter format: "es"
here and console.log what the code actually is, you will see that it is invalid as tries to assign something to a non-existing (in an ES module) module.exports
, which would throw at runtime.
Not sure we can keep it as it is. The only way to fix this is to get rid of all exports, which seems rather complex for me considering it is not entirely sure how this feature will evolve.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I logged the test result, and it does not seem to generate anything invalid.
It's assigning to module.exports
while module
is valid and passed as an argument from commonjsRegister
's callback.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry, did not read your reply properly, will need to have another look again myself
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh you are right and I stand corrected. In that case there is no issue from my side.
I'm fine with putting this on hold, if there's work to resolve that |
c7fb33c
to
64ce73e
Compare
@danielgindi I merged your previous PR and it caused a few conflicts. Please have a look and we'll merge |
…njsModule(...)` This happens when the code has an strong indicator for wrapping, like /__esModule/.test(code)
64ce73e
to
b511a5d
Compare
@shellscape Rebased |
Rollup Plugin Name:
commonjs
This PR contains:
Are tests included?
Breaking Changes?
Description
In cases where the code has an strong indicator for wrapping, like
/__esModule/.test(code)
, thetransform
forces the code to be wrapped in acreateCommonjsModule
.This is redundant when the code is already a
commonjsRegister
call, as it registers a module with full commonjs mechanics.(Of course the specific case outlined with
/__esModule/
is not the best and there's a// TODO handle transpiled modules
in the code over there.But there are multiple indicators for wrapping, and this could be avoided. It's just extra mess that does not hurt, but does not contribute anything.
The result of the wrapped module is not used anywhere, it just calls the
commonjsRegister
inside thecreateCommonjsModule
.