You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When normal resolution fails to find node types, resolve to globally installed (or bundled?) @types/node as a fallback
When using implicit tsconfig, detect presence of @types/node either locally or globally, and reference "node" types automatically.
Use-case is scripts like this which want to rely totally on globally-installed ts-node:
#!/usr/bin/env ts-node
// do stuff using node APIs; should typecheck
process.env['foo']
Use-cases
.ts script with shebang and no tsconfig
import {readFileSync} from 'fs'; should pass typechecking without any ceremony
should import all discovered node_modules/@types? Is slower but a more automatic default
.ts script with tsconfig.json
we should match the way tsserver, tsc, and language service behave. We can resolve node to our local copy if it's not found elsewhere, but we should not otherwise affect behavior. If someone says "types": [] then we respect that
.ts script with tsconfig.json that extends ts-node/node14/tsconfig.json
this implies ts-node is installed locally, and our node peerDep is installed, meaning the user will get node typings. They can specify their own types array, too, and it will behave.
Implementation notes
Ideally we would override ts.getAutomaticTypeDirectiveNames to add node to the array. However, this function is not exposed for overriding on any *Host interface
TODOs
add "node" to the re-exported @tsconfig/bases lib arrays
add tests that our lib array matches the @tsconfig/bases array
rethink this; will break automatic parsing of other @types in the local directory? No because when you have a local directory anyway, you can easily create a tsconfig.json
Declare "@types/node": "*" as a peerDependency to be automatically installed? Same as typescript; ensures npm install -g works out-of-the-box
The text was updated successfully, but these errors were encountered:
When normal resolution fails to find
node
types, resolve to globally installed (or bundled?)@types/node
as a fallbackWhen using implicit tsconfig, detect presence of @types/node either locally or globally, and reference "node" types automatically.
Use-case is scripts like this which want to rely totally on globally-installed ts-node:
Use-cases
.ts
script with shebang and no tsconfigimport {readFileSync} from 'fs';
should pass typechecking without any ceremonynode_modules/@types
? Is slower but a more automatic default.ts
script with tsconfig.jsonnode
to our local copy if it's not found elsewhere, but we should not otherwise affect behavior. If someone says"types": []
then we respect that.ts
script with tsconfig.json that extendsts-node/node14/tsconfig.json
ts-node
is installed locally, and ournode
peerDep is installed, meaning the user will get node typings. They can specify their owntypes
array, too, and it will behave.Implementation notes
Ideally we would override
ts.getAutomaticTypeDirectiveNames
to addnode
to the array. However, this function is not exposed for overriding on any*Host
interfaceTODOs
add "node" to the re-exported @tsconfig/bases lib arrays"@types/node": "*"
as a peerDependency to be automatically installed? Same as typescript; ensuresnpm install -g
works out-of-the-boxThe text was updated successfully, but these errors were encountered: