-
Notifications
You must be signed in to change notification settings - Fork 28.3k
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
repl / eval: CommonJS globals leak into ESM modules #30842
Comments
I think the only way to fix this would be some trickery with virtual |
Why is this an issue? Imo repl does not have to be spec compliant. Also there is no spec for |
@hashseed note that according to the OP it happens for |
i mean ideally we want to avoid cjs locals leaking into modules (and other places). if v8 is not willing to accept such a change we can call this "won't fix" (and i won't be that broken up about it) but imo it would be nice to fix. |
I think you misread the first paragraph: It sounds like in the @devsnek Would it be possible to use the |
@jkrems that's not quite true. |
Oh, we set them as globals there, too? That’s definitely weird. Don’t see why we need for —eval. |
For Inside |
I wish there was a comment in that file explaining why we're not using the typical function wrapper. Is it "because it would be a breaking change" at this point..? First level of blame doesn't show anything obvious. |
@jkrems --print 1 needs to print 1, so wrapping it in a function wouldn't work. |
Gotcha, thanks for the explanation! But v8-inspector and console API may be a possible path for |
@jkrems inspector doesn't introduce new magic scope. in fact, that would also be an issue with the virtual with repl we can transform the code arbitrarily and no one will really care, so we can fix it with enough effort, but for |
Ah, the console API is also available for all other code running, not just the evaluated expression? That's too bad. :( The upside is that it gets automatically removed once the initial evaluation stops (doesn't survive to future ticks) but I'm not sure if that's enough for this..? As long as ESM doesn't run in the same tick, it wouldn't see the |
Since there is no viable route forward here, and the design decisions in V8 encapsulation and the Node.js REPL have been made, closing this as a "wontfix". |
This is still on my list of things to fix if ever possible |
Linux lt2.cfware.com 5.3.11-200.fc30.x86_64 #1 SMP Tue Nov 12 19:25:25 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
--eval
and--print
without--input-type=module
Create
script.mjs
:Running
node ./script.mjs
ornode --input-type=module --eval "import('./script.mjs')"
both produce the correct outputscript.mjs undefined
.Now run
import('./script.mjs')
in repl, this produces outputscript.mjs function
. Same fornode --eval "import('./script.mjs')"
.Using
--print
in place of--eval
does not changetypeof require
.CC @nodejs/modules-active-members
The text was updated successfully, but these errors were encountered: