REPL crashes after let process;

[mik-jozef]

• Version: v6.0.0
• Platform: Windows 10 64bit
• Subsystem: REPL

Steps to replicate:

1. Open REPL
2. Type "let process;"

Node crashes instead of displaying something like TypeError: Identifier 'process' has already been declared.

[bnoordhuis]

let process is basically equivalent to process = undefined because it runs in the top-level (i.e., global) scope.

The REPL (and node in general) will let you do that but it won't end well. let Object or let Array have the same issue. I don't know if I'd say this is an actual bug, just mildly unexpected behavior.

[mik-jozef]

But why crash instead of displaying an error as if I typed "let x" two times?

[Fishrock123]

Interesting. var process; doesn't crash. Here's the stack:

> var process
undefined
> let process
undefined
domain.js:99
        process._emittingTopLevelDomainError = false;
                                             ^

TypeError: Cannot set property '_emittingTopLevelDomainError' of undefined
    at Domain.errorHandler [as _errorHandler] (domain.js:99:46)
    at process._fatalException (node.js:265:33)

[jasnell]

More interesting is that var process; does not actually redefine process

> var process;
undefined
> process;
{ process object output }

As @bnoordhuis indicates, I don't think this is an actual bug but it is rather odd.

[Fishrock123]

cc @nodejs/v8 probably

[bnoordhuis]

More interesting is that var process; does not actually redefine process

That's consistent with var semantics, it reuses the existing 'slot' if there is one.

The undefined return value that the REPL prints is because var process; is a statement that doesn't produce a value.

[addaleax]

Confirmed that this would be fixed by #5703 while going through the open PRs.

[lance]

This does not seem like a bug to me.

> let process;

This creates a process variable in the current lexical environment, shadowing the global process object. It's uninitialized, therefore undefined, but node depends on the process object, and now it's undefined. There is no way to recover from this.

@mik-jozef what would you suggest, display an error and then what? There's no way to continue with process now undefined. You could isolate this assignment in its own lexical environment, similar to this below, but there is no way at the top level to set process to something else and expect it to not be broken.

> function foo() {
... let process;
... console.log(process.nextTick);
... }
undefined
> console.log(process.nextTick);
[Function: nextTick]
undefined
> foo();
TypeError: Cannot read property 'nextTick' of undefined
    at foo (repl:3:20)
    at repl:1:1
    at REPLServer.defaultEval (repl.js:272:27)
    at bound (domain.js:280:14)
    at REPLServer.runBound [as eval] (domain.js:293:12)
    at REPLServer.<anonymous> (repl.js:441:10)
    at emitOne (events.js:101:20)
    at REPLServer.emit (events.js:188:7)
    at REPLServer.Interface._onLine (readline.js:219:10)
    at REPLServer.Interface._line (readline.js:561:8)
>  console.log(process.nextTick)
[Function: nextTick]
undefined
>

As for var process, as @bnoordhuis said, this is how var works. From the ES2015 spec, "Within the scope of any VariableEnvironment a common BindingIdentifier may appear in more than one VariableDeclaration but those declarations collective define only one variable." So just typing var process doesn't do anything at all, really. Try typing var process = undefined and you'll find that the behavior is the same as that of let because now that common variable name has been redefined.

@addaleax I'm not sure how #5703 would affect this. In fact, all of the examples I've shown in this comment were run on that branch. Can you help me understand what would be different here?

[cjihrig]

By not using the global context, you can define a variable named process without overwriting Node's global.

[lance]

@cjihrig ok that makes sense, of course. I'll take a look at the PR and write a test.