Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ts-node ./index may execute the wrong file extension because tsconfig search poisons the require.resolve cache #1220

Closed
cspotcode opened this issue Feb 15, 2021 · 0 comments · Fixed by #1155
Milestone

Comments

@cspotcode
Copy link
Collaborator

cspotcode commented Feb 15, 2021

Fixed in #1155, creating this issue as documentation.

In order to locate tsconfig files relative to entrypoint scripts, we use require.resolve to resolve the entrypoint's location on disk, then search from there. We do this resolution without knowing if --prefer-ts-exts is enabled or not. This means our initial resolution may resolve to index.js, even though we are supposed to execute index.ts.

require.resolve is cached. This means we may poison the cache with ./index.js. When we require('./index') it will be the wrong file.

The fix, implemented in #1155, is a hack which prevents node from caching our initial resolution.

Node 10 known limitation

This fix is disabled in node versions less than 12.x because it triggers a node bug where resolution is mysteriously done relative to cwd. This means node 10 and 11 will still exhibit this bug. Node 10 is EOL in 2 1/2 months on 2021-04-30. https://nodejs.org/en/about/releases/ Node 11 is already unmaintained.

Additionally, I'm pretty sure this bug is extremely rare. It would only manifest if a project was doing all of the following:

  • specifying entrypoint without file extension
  • Using --prefer-ts-exts
  • multiple extensions with the same filename exist on disk (e.g. index.ts and index.js)
cspotcode added a commit that referenced this issue Feb 16, 2021
…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
@cspotcode cspotcode added this to the 10.0.0 milestone May 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant