`Cannot find module 'typescript'` when using `npx ts-node`

[janpio]

We have been using npx ts-node to run a specific script for quite some while now, and with update 10.2.0 that script started to fail.

Expected Behavior

Script works.

Actual Behavior

Cannot find module 'typescript'
Require stack:
- /home/runner/.npm/_npx/2763/lib/node_modules/ts-node/dist/index.js
- /home/runner/.npm/_npx/2763/lib/node_modules/ts-node/dist/repl.js
- /home/runner/.npm/_npx/2763/lib/node_modules/ts-node/dist/bin.js

Steps to reproduce the problem

prisma/ecosystem-tests#1982

Minimal reproduction

Specifications

• ts-node version: 10.2.0
• node version: 12.22.4
• TypeScript version: -
• tsconfig.json, if you're using one:

{
  "compilerOptions": {
    "esModuleInterop": true,
    "lib": ["ESNext", "dom"]
  }
}

• Operating system and version: Ubuntu 20.04.2 LTS (GH Actions)
• If Windows, are you using WSL or WSL2?:

[cspotcode]

We declare typescript as a peerDependency. I would check if npx is installing peerDependencies or if you are required to do something else to make it install them. Also check the version of npx and npm; might be relevant.

[janpio]

Thanks, I will try to get to that later.

Right now I just wanted to report that this new release is causing trouble for us where everything worked fine before.

Adding ts-node as a devDependency to our package.json files actually made the problem go away as well it might seem (vs. fully relying on npx ts-node to download and run the correct tings), not 100% sure yet. CI is still running - will report back.

[cspotcode]

Always good to get the bug report. However, in this case, we didn't change anything with our typescript dependency declaration, so I don't think there's anything we should change to avoid what I assume is an npx limitation. If npx does not install peerDependencies, then you'll need to avoid npx. But I bet it has a flag to install them; this is probably in their documentation.

Here are the code changes between 10.1.0 and 10.2.0
v10.1.0...v10.2.0

[janpio]

The funny bit here is that the environment, as far as we can figure out, is absolutely identical:

https://github.com/prisma/e2e-tests/runs/3267534138
https://github.com/prisma/e2e-tests/runs/3278404357

node: v12.22.4
npm: 6.14.14 

(npx is the same as npm)

Once the npx ts-node ... works, once it does not.

Unfortunately this npx does not output the version it downloaded, installed and ran :/

But you are right, this is most probably not a ts-node problem but something with the environment we are running this in.

[cspotcode]

Here is a demo that shows this is an npx issue.

It runs 6x different test cases. The differentiating factor appears to be npx version.

https://github.com/TypeStrong/ts-node-repros/blob/cspotcode-patch-1/run.sh
https://github.com/TypeStrong/ts-node-repros/runs/3285806806

[janpio]

This is definitely something about npx, but the two test runs I linked above both ran with node: v12.22.4; npm: 6.14.14 so it might not be as easy as a new npx version (which should be pinned to the npm version).

To repeat our "fix":
We fixed it by adding the ts-node version to our package.json file in the project. Seems that makes npx behave differently.

[wandyezj]

May have something to do with npx, but it seems strange that for the same npx version 6.14.9

npx ts-node --version fails
and
npx ts-node@10.1.10 --version succeeds.

This would seem to indicate a change in ts-node not npx.

[cspotcode]

Could also be a module hoisting issue, where it was never supposed to work, but it did accidentally due to npm's hoisting.

What change should we make in ts-node? The typescript peerDependency didn't change so we shouldn't change that.

[wandyezj]

Do you have a script to narrow down which commit causes a specific issue?

Something like:

for a set of commits:

• move repository to commit
• build
• run test script that identifies the issue

There seem to be ~14 commits: v10.1.0...v10.2.0 to try.

(Since commits are linear, it's possible to optimize and apply a binary search, but that's not needed since there are relatively few commits in this case)