Unable to require .ts nested within a node_modules directory

[underflow00]

Expected Behavior

No errors.

Actual Behavior

"Unable to require file" error.

Steps to reproduce the problem

1. Create a package (e.g. using npm pack) with the following files:

• npm-postinstall.ts:

console.log('hello');
import * as x from './x';
console.log('hello2', typeof x);

• package.json:

{
  "name": "package1",
  "version": "0.0.0",
  "scripts": {
    "postinstall": "ts-node --skip-ignore npm-postinstall"
  },
  "dependencies": {
    "ts-node": "^8.6.2",
    "typescript": "^3.7.5"
  }
}

• x.ts:

export const x = 1;

2. Install that package: npm install package1-0.0.0.tgz

Works fine on Windows

Specifications

• ts-node version: 8.6.2
• node version: 12.15.0
• Operating system and version: Ubuntu
• If Windows, are you using WSL or WSL2?:

[underflow00]

Not a ts-node issue apparently. See microsoft/TypeScript#12358. Workaround is to use --transpile-only.

[cspotcode]

@underflow00
Thanks for reporting. I think I have an easy workaround for you, at the bottom of this comment. Pass --files instead of --skip-ignores.

If I understand correctly, the TypeScript compiler refuses to compile anything inside a node_modules directory unless included via "includes" or "files" arrays. When these arrays are omitted, it includes everything in the working directory excluding nested node_modules.

You can workaround this limitation by passing --files to ts-node. This prevents ts-node from passing empty "files" and "include" arrays. When we don't pass any value for those arrays, the compiler defaults to including everything in the working directory. You don't even need a tsconfig file for this: it will include npm-postinstall.ts and x.ts by default, and your postinstall script will work.

  "scripts": {
    "postinstall": "ts-node --files npm-postinstall"
  },

EDIT: repro branch for future reference: https://github.com/TypeStrong/ts-node-repros/commits/956

[cspotcode]

I'm reopening this because I think it might be a ts-node problem, or at least something that we can fix on our end.

Based on the issue linked here (#956 (comment)) it sounds like we can implement the host API's resolveModuleNames to tell TypeScript if files are considered "external." I'm guessing the default compiler behavior is to check if we're inside a node_modules directory. But for us, it seems smarter to check only for node_modules directories that are either nested within our project directory or entirely outside of project.

For example, if project is /project/node_modules/module1, we should compile / not compile the following files:

/project/node_modules/module1/foo.ts -> YES, compile
/project/node_modules/module1/bar.ts -> YES, compile
/project/node_modules/module1/node_modules/other/src/index.ts -> NO, do not compile
/project/node_modules/other/src/index.ts -> NO, do not compile

[cspotcode]

Linking to a related TypeScript issue: microsoft/TypeScript#28432 (comment)

The behavior proposed in that comment matches what I described in my previous comment.

I'm not yet sure if isExternalLibraryImport makes the compiler behaves differently in other ways, other than emitting / not emitting. Is type-checking affected?

Do we need to compute isExternalLibraryImport based solely on ts-node's --ignore pattern? Will typechecking be adversely affected, where type errors appear and disappear based on the --ignore value?

If we compute isExternalLibraryImport in a way that differs from --ignore, then there's a possibility that ts-node wants to compile a file but the compiler decides it should not emit.