CommonJS arguments shouldn't be treated as globals in node

TypeScript Version: typescript@3.9.0-dev.20200212

Search Terms:

• node
• global
• __dirname

Code

// This should fail unless we target CommonJS.
// It could succeed when targeting CommonJS.
const s: string = __dirname;

// This should always succeed when including the node types
const i: number = process.pid;

Expected behavior:

• process (and other node globals) are defined.
• __dirname (and other CJS arguments) aren’t defined.

Actual behavior:

• Including @types/node always defines both true globals and CJS arguments as globals.

Playground Link: The playground doesn’t seem to easily support adding the node typings but here’s a gist: https://gist.github.com/jkrems/f97d0e040f82c3c4120ca8d3f2fe2fff. The gist comes with a failing test case, allowing npm it after clone.

Related Issues:

• The original bug against @types/node: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/42201
• General issue for module support in Typescript code targeting node: https://github.com/microsoft/TypeScript/issues/18442

[kitsonk]

Why wouldn’t this be a @types/node issue and should offer a set of CommonJS globals, and a set of ESM globals, depending on what the user is doing. Just like TypeScript doesn’t include node libs, it is something a user is asserting.

[RyanCavanaugh]

There’s no way we’d do something this complicated for the sake of a handful of globals that already start with underscores unless it was something people were constantly getting tripped up on. It’s not even clear it’d be a correct error when issued, since you may very well be targeting ESNext modules and having a downstream build step convert to CommonJS