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
Changes such as making --script-mode the default are meant to make scripts and script projects more portable & self-contained. If a script lives in a directory with a tsconfig.json, and that directory also has a node_modules/typescript installed, then loading that tsconfig means also using that compiler. This matches other tsc, node, and ts-node behaviors. For example:
tsc resolves "extends": "@tsconfig/node14" relative to the location of the tsconfig.json, as if the tsconfig.json had "require"ed @tsconfig/node14
ts-node resolve "require" options specified in a tsconfig.json relative to the tsconfig.json file, as if it had required them
node sets its behaviors for a file based on locating the nearest package.json relative to the file being executed, not relative to CWD (for example it consults package.json "type" field to determine CJS vs ESM)
I believe we mostly already did this, since --script-mode already set the cwd to be the directory containing the script. However, it's technically possible (though extremely rare) that the entry-point script would resolve a different compiler than the tsconfig file, if the 2 were in different directories. ./tsconfig.json would resolve to ./node_modules/typescript whereas ./src/index.ts would resolve to ./src/node_modules/typescript
But again, I think that's very rare. The important thing is that we find the compiler relative to the tsconfig.json, which will typically exist at or near the project root.
The text was updated successfully, but these errors were encountered:
…behavior; other cwd, project, and dir fixes (#1155)
* Use `--script-mode` by default
* Add `--cwd-mode` flag to opt-out of `--script-mode`
* Add `ts-node-cwd` entry-point that uses `--cwd-mode` by default
* Rename `--dir` to `--cwd`; `TS_NODE_DIR` to `TS_NODE_CWD`; parse legacy names for backwards compatibility
* Rewrite `--cwd` docs to say it changes effective `cwd`
* Add `projectSearchDir` API option to set directory from which tsconfig search is performed
* Fix bug where resolving entry-point location could poison `require.resolve` cache and prevent correct extension from loading (#1220)
* `--cwd` no longer sets `--scope`
* Remove `--scope` from CLI flags and tsconfig-loaded options; it is an API-only option, to match the intended use-case: programmatically installing multiple ts-node instances
* Add `scopeDir` API option
* Deprecate `TS_NODE_SCOPE` env var
* `ignore` rules evaluated relative to `tsconfig.json`, otherwise `cwd`; no longer tied to `--dir`
* `compiler` is loaded relative to `tsconfig.json` instead of `cwd` or entrypoint script (#1225)
---
*Original GH-generated squash summary*
* make --script-mode the default; add --cwd-mode to switch back to old behavior
* Fix bug where --script-mode entrypoint require.resolve poisons the require.resolve cache; causes entrypoint to resolve incorrectly when --prefer-ts-exts is used
* WIP TODO amend / rewrite this commit
* wip
* WIP
* add ts-node-cwd bin, which is equivalent to ts-node --cwd-mode
* rename projectSearchPath to projectSearchDir
* Revert undesirable changes from WIP commits
* add --cwd-mode and --script-mode tests
* revert undesirable logging from WIP commits
* update tests which relied on --dir affecting to cwd to instead use projectSearchDir as needed
* remove --script-mode from test invocations that don't need it anymore
* fix lint failures
* fix tests
* fix requireResolveNonCached to avoid hack on node 10 & 11
* fix tests to avoid type error on ts2.7
* fix tests on node 10
* update README and final cleanup
* more cleanup
* Load typescript compiler relative to tsconfig.json
Implemented by #1155
Changes such as making
--script-mode
the default are meant to make scripts and script projects more portable & self-contained. If a script lives in a directory with atsconfig.json
, and that directory also has anode_modules/typescript
installed, then loading that tsconfig means also using that compiler. This matches other tsc, node, and ts-node behaviors. For example:"extends": "@tsconfig/node14"
relative to the location of the tsconfig.json, as if the tsconfig.json had "require"ed @tsconfig/node14I believe we mostly already did this, since
--script-mode
already set thecwd
to be the directory containing the script. However, it's technically possible (though extremely rare) that the entry-point script would resolve a different compiler than the tsconfig file, if the 2 were in different directories../tsconfig.json
would resolve to./node_modules/typescript
whereas./src/index.ts
would resolve to./src/node_modules/typescript
But again, I think that's very rare. The important thing is that we find the compiler relative to the tsconfig.json, which will typically exist at or near the project root.
The text was updated successfully, but these errors were encountered: