Skip to content

Lexical variable declarations (let, const) unusable in repl if error thrown during declaration/first assignment #8309

Description

@polybuildr
  • Version: v.6.3.1
  • Platform: Linux (Ubuntu 14.04)
  • Subsystem: repl (I think)
let s = Set();

gives TypeError: Constructor Set requires 'new'.

However, after this:

s

gives ReferenceError: s is not defined

and

let s = new Set();

gives TypeError: Identifier 's' has already been declared.

I'm not sure whether this is a real bug or it's expected behaviour, but it sure does seem unusual that s becomes unusable from this point in in the repl.

This isn't a problem when running node on a js file because the TypeError simply terminates execution.

Activity

  1. added
    replIssues and PRs related to the REPL subsystem.
    on Aug 28, 2016
  2. vsemozhetbyt commented on Aug 28, 2016

    @vsemozhetbyt
    Contributor

    Different with var:

    > var  s = Set();
    TypeError: Constructor Set requires 'new'
    > s
    undefined
    > var  s = new Set();
    undefined
    > s
    Set {}
    
  3. polybuildr commented on Aug 28, 2016

    @polybuildr
    Author

    Yep, works fine with var.

  4. vkurchatkin commented on Aug 28, 2016

    @vkurchatkin
    Contributor

    Here is simplified test case:

    var vm = require('vm');
    
    try {
      vm.runInThisContext('let x = f');
    } catch (e) {}
    
    vm.runInThisContext('x = 1');
  5. added
    vmIssues and PRs related to the vm subsystem.
    on Aug 28, 2016
  6. addaleax commented on Aug 28, 2016

    @addaleax
    Member

    This is very déjà-vu-ish to me, although I can’t find another issue for this bug… /cc @nodejs/v8?

  7. polybuildr commented on Aug 28, 2016

    @polybuildr
    Author

    This error also occurs in the Chrome browser, so it's probably a v8 thing and not a Node thing. Sorry for reporting it in the wrong place.

  8. polybuildr commented on Aug 28, 2016

    @polybuildr
    Author

    Where should I report this considering that it's not specific to node's repl?

  9. Fishrock123 commented on Aug 28, 2016

    @Fishrock123
    Contributor

    I wouldn't be surprised if this was how the spec worked.

    In general, you'll have a better time using var for variables in the repl.

  10. bnoordhuis commented on Aug 29, 2016

    @bnoordhuis
    Member

    @polybuildr You can report it over at https://bugs.chromium.org/p/v8/issues/list. It looks spec compliant to me (the binding for s is never fully constructed and stays in the TDZ) but perhaps the error messages can be improved.

  11. Slayer95 commented on Aug 29, 2016

    @Slayer95
    Contributor
  12. polybuildr commented on Aug 29, 2016

    @polybuildr
    Author

    @bnoordhuis, @Slayer95, it does look spec-compliant, so I'm going to close this issue. However, that esdiscuss topic pointed me to something interesting that the Firefox Devtools console does and might be worth a shot.

    For any such unresolved bindings (at least in the DevTools), Firefox steps in and turns them into undefined. So a redeclaration with let doesn't work, but simply s = 5 works from that point on. If anyone would like to consider doing this for the repl, feel free to reopen the issue.

  13. MasterJames commented on Jun 9, 2018

    @MasterJames

    Not working all variations

    > rangeArray = nj.arange(6,12)
    ReferenceError: rangeArray is not defined
    > rangeArray = new nj.arange(6,12)
    ReferenceError: rangeArray is not defined
    > var rangeArray = new nj.arange(6,12)
    SyntaxError: Identifier 'rangeArray' has already been declared
    > let rangeArray = new nj.arange(6,12)
    SyntaxError: Identifier 'rangeArray' has already been declared
    > let rangeArray = nj.arange(6,12)
    SyntaxError: Identifier 'rangeArray' has already been declared
    > var rangeArray = nj.arange(6,12)
    SyntaxError: Identifier 'rangeArray' has already been declared
    
    
  14. gireeshpunathil commented on Mar 16, 2020

    @gireeshpunathil
    Member
  15. 14 remaining items

  16. ankit142 commented on Feb 15, 2024

    @ankit142
  17. gregfenton commented on Feb 15, 2024

    @gregfenton

    @ankit142 The issue as posted isn't about fixing the code in the example provided. There are many examples that could be provided.

    Essentially this issue is that calling let x = <some_code_that_throws_an_error> leads to a situation where you cannot use x and you cannot redeclare let x. So for the remainder of the REPL session, the symbol x is unusable.

  18. ankit142 commented on Feb 15, 2024

    @ankit142
  19. gregfenton commented on Feb 15, 2024

    @gregfenton

    Again, the issue is not with "fixing the code". It is a bad behaviour of the REPL. You don't know that the code you just typed will hit an error. It does. The symbol you tried to use (x) is now unusable for the remainder of the REPL.

    This isn't about "writing good code" vs. "writing bad code". This is about the user experience using the REPL when playing around with code.

    • Why would someone do this?
      • developer trying stuff -- copy/paste instructions from somewhere or whatever
    • Why not just use another symbol once x is unusable?
      • other code coming (think copy/paste instructions) leverages that same symbol; the user would be forced to either stop/restart the REPL or refactor the code they are about to paste
        • both of the workarounds above are not a good/healthy user experience
  20. avivkeller commented on Jun 5, 2024

    @avivkeller
    Member
  21. eberestbacalso8-ui commented on Dec 3, 2025

    @eberestbacalso8-ui
  22. github-actions commented on Jul 3, 2026

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

  23. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Jul 3, 2026
  24. added
    confirmed-bugIssues and PRs for confirmed bugs.
    and removed
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Jul 3, 2026
  25. self-assigned this
    on Jul 3, 2026
  26. added a commit that references this issue on Jul 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

confirmed-bugIssues and PRs for confirmed bugs.replIssues and PRs related to the REPL subsystem.vmIssues and PRs related to the vm subsystem.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions