Skip to content

repl / eval: CommonJS globals leak into ESM modules #30842

Closed as not planned
Closed as not planned
repl / eval: CommonJS globals leak into ESM modules#30842
Assignees
devsnek
Labels
cliIssues and PRs related to the Node.js command-line interface.esmIssues and PRs related to the ECMAScript Modules implementation.experimentalIssues and PRs related to experimental features.replIssues and PRs related to the REPL subsystem.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

Description

@coreyfarrell
coreyfarrell
opened on Dec 7, 2019
  • Version: v14.0.0-pre / cf5ce2c
  • Platform: 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
  • Subsystem: repl, CLI --eval and --print without --input-type=module

Create script.mjs:

console.log('script.mjs', typeof require);

Running node ./script.mjs or node --input-type=module --eval "import('./script.mjs')" both produce the correct output script.mjs undefined.

Now run import('./script.mjs') in repl, this produces output script.mjs function. Same for node --eval "import('./script.mjs')".

Using --print in place of --eval does not change typeof require.

CC @nodejs/modules-active-members

Activity

  1. devsnek
    self-assigned this
    on Dec 7, 2019
  2. devsnek
    added
    cliIssues and PRs related to the Node.js command-line interface.
    esmIssues and PRs related to the ECMAScript Modules implementation.
    experimentalIssues and PRs related to experimental features.
    replIssues and PRs related to the REPL subsystem.
    on Dec 7, 2019

  3. devsnek commented on Dec 7, 2019

    @devsnek
    devsnek
    on Dec 7, 2019
    Member

    I think the only way to fix this would be some trickery with virtual with contexts (like the context_extensions option of CompileFunctionInContext). @hashseed does adding such an option to normal script compilation seem reasonable?

  4. hashseed commented on Dec 8, 2019

    @hashseed
    hashseed
    on Dec 8, 2019
    Member

    Why is this an issue? Imo repl does not have to be spec compliant. Also there is no spec for require.

  5. ljharb commented on Dec 8, 2019

    @ljharb
    ljharb
    on Dec 8, 2019
    SponsorMember

    @hashseed note that according to the OP it happens for node --eval as well, so it's not just the repl.

  6. devsnek commented on Dec 8, 2019

    @devsnek
    devsnek
    on Dec 8, 2019
    Member

    Imo repl does not have to be spec compliant. Also there is no spec for require.

    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.

  7. hybrist commented on Dec 9, 2019

    @hybrist
    hybrist
    on Dec 9, 2019
    Contributor

    note that according to the OP it happens for node --eval as well, so it's not just the repl.

    I think you misread the first paragraph: It sounds like in the --eval case, the module logs undefined as expected. This only happens in the repl.

    @devsnek Would it be possible to use the RuntimeAgent.evaluate for the repl with require from the console API instead from global? That should prevent it from leaking into the global scope and it wouldn't appear in "normal" code while still working in the repl expressions. That would also move it closer to the way the repl in devtools/debug clients works.

  8. coreyfarrell commented on Dec 9, 2019

    @coreyfarrell
    coreyfarrell
    on Dec 9, 2019
    MemberAuthor

    @jkrems that's not quite true. --eval with --input-type=module does the right thing but the commonjs variables are leaked when node --eval is used without --input-type=module.

  9. hybrist commented on Dec 9, 2019

    @hybrist
    hybrist
    on Dec 9, 2019
    Contributor

    Oh, we set them as globals there, too? That’s definitely weird. Don’t see why we need for —eval.

  10. coreyfarrell commented on Dec 9, 2019

    @coreyfarrell
    coreyfarrell
    on Dec 9, 2019
    MemberAuthor

    For --eval and --print run without --input-type=module they're set here:
    https://github.com/nodejs/node/blob/master/lib/internal/process/execution.js#L75-L79

    Inside script the commonjs variables are function arguments created by vm.compileFunction so I assume they're being copied to global to become available inside vm.runInThisContext.

  11. hybrist commented on Dec 9, 2019

    @hybrist
    hybrist
    on Dec 9, 2019
    Contributor

    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.

  12. devsnek commented on Dec 9, 2019

    @devsnek
    devsnek
    on Dec 9, 2019
    Member

    @jkrems --print 1 needs to print 1, so wrapping it in a function wouldn't work.

  13. hybrist commented on Dec 9, 2019

    @hybrist
    hybrist
    on Dec 9, 2019
    Contributor

    Gotcha, thanks for the explanation! But v8-inspector and console API may be a possible path for --print/--eval I assume?

  14. devsnek commented on Dec 9, 2019

    @devsnek
    devsnek
    on Dec 9, 2019
    Member

    @jkrems inspector doesn't introduce new magic scope. in fact, that would also be an issue with the virtual with scope, so i guess that won't work either...

    with repl we can transform the code arbitrarily and no one will really care, so we can fix it with enough effort, but for --eval we need to keep everything exact, and i can't think of a way to make it work.

  15. hybrist commented on Dec 9, 2019

    @hybrist
    hybrist
    on Dec 9, 2019
    Contributor

    inspector doesn't introduce new magic scope.

    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 require anymore.

  16. guybedford commented on Mar 12, 2020

    @guybedford
    guybedford
    on Mar 12, 2020
    Contributor

    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".

  17. guybedford
    closed this as completedon Mar 12, 2020
  18. devsnek
    reopened this on Mar 12, 2020

  19. devsnek commented on Mar 12, 2020

    @devsnek
    devsnek
    on Mar 12, 2020
    Member

    This is still on my list of things to fix if ever possible

  20. github-actions commented on Jun 27, 2026

    @github-actions
    github-actionsBot
    on Jun 27, 2026 – with GitHub Actions
    Contributor

    This issue has been marked as stale due to 210 days of inactivity.
    It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

  21. github-actions commented on Jul 28, 2026

    @github-actions
    github-actionsBot
    on Jul 28, 2026 – with GitHub Actions
    Contributor

    This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
    If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

cliIssues and PRs related to the Node.js command-line interface.esmIssues and PRs related to the ECMAScript Modules implementation.experimentalIssues and PRs related to experimental features.replIssues and PRs related to the REPL subsystem.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions