Repository navigation
Lexical variable declarations (let, const) unusable in repl if error thrown during declaration/first assignment #8309
Description
Activity
- addedreplIssues and PRs related to the REPL subsystem.Issues and PRs related to the REPL subsystem.
on Aug 28, 2016 Different with
var:> var s = Set(); TypeError: Constructor Set requires 'new' > s undefined > var s = new Set(); undefined > s Set {}Yep, works fine with
var.Here is simplified test case:
var vm = require('vm'); try { vm.runInThisContext('let x = f'); } catch (e) {} vm.runInThisContext('x = 1');
- addedvmIssues and PRs related to the vm subsystem.Issues and PRs related to the vm subsystem.
on Aug 28, 2016 This is very déjà-vu-ish to me, although I can’t find another issue for this bug… /cc @nodejs/v8?
Reacted by Prince John Wesley and Juliette WangThis 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.
Where should I report this considering that it's not specific to node's repl?
I wouldn't be surprised if this was how the spec worked.
In general, you'll have a better time using
varfor variables in the repl.Reacted by Sohang Chopra@polybuildr You can report it over at https://bugs.chromium.org/p/v8/issues/list. It looks spec compliant to me (the binding for
sis never fully constructed and stays in the TDZ) but perhaps the error messages can be improved.This is per spec: https://esdiscuss.org/topic/take-let-variable-out-of-temporal-dead-zone
@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
letdoesn't work, but simplys = 5works from that point on. If anyone would like to consider doing this for the repl, feel free to reopen the issue.Reacted by Sohang ChopraNot 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 declaredre-opening, per #32288 (comment), #32288 (comment) and #32288 (comment)
14 remaining items
@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 usexand you cannot redeclarelet x. So for the remainder of the REPL session, the symbolxis unusable.Reacted by Sohang ChopraAgain, 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
xis 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
- 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
Reacted by Gabriel Poussif, Alan Johnson, Luiz Victor Linhares Rocha, Tira Odhner, Patrick Leiser and Graham Snyder- Why would someone do this?
FWIW @1Git2Clone has a issue with chromium at https://issues.chromium.org/issues/345248266.
Reacted by Sohang Chopra- marked A way to forget a variable in Node.js REPL? #56752 as a duplicate of this issue
on Feb 3, 2025 eberestbacalso8-ui commented
on Dec 3, 2025 on Dec 3, 2025 · Hidden as off-topicshow commentMore actionsThis 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.- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jul 3, 2026 - addedconfirmed-bugIssues and PRs for confirmed bugs.Issues and PRs for confirmed bugs.and removedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jul 3, 2026
repl(I think)gives
TypeError: Constructor Set requires 'new'.However, after this:
gives
ReferenceError: s is not definedand
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
sbecomes unusable from this point in in the repl.This isn't a problem when running
nodeon a js file because the TypeError simply terminates execution.