CommonJS arguments shouldn't be treated as globals in node
See original GitHub issueTypeScript 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
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:9 (4 by maintainers)
Top Results From Across the Web
CommonJS vs ES Modules in Node.js - A Detailed Comparison
Check CommonJS vs ES modules comparision when using them in Node.js apps. ... An easy way to tell Node.js to treat the modules...
Read more >javascript - Define global variable before importing ES6 module
I used to do that with CommonJS in my main file: const path = require('path'); global. appRoot = path. resolve(__dirname); const myObj = ......
Read more >When will CommonJS modules (require) be deprecated and ...
So, no, I don't think we're anywhere close to Deprecating CommonJS in Node.js... at least not from the point of view of removing...
Read more >Using ES modules in Node.js - LogRocket Blog
Learn about the state of ES modules in Node today, including concerns realted to transitioning from and interoperability with CommonJS.
Read more >Node Modules at War: Why CommonJS and ES ... - Code Red
ESM scripts use Strict Mode by default ( use strict ), their this doesn't refer to the global object, scoping works differently, etc....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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.
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