Module nodenext is resolving to cjs build incorrectly

[perrin4869]

Search Terms

nodenext

Expected Behavior

tsc and ts-node resolve to the same modules when using nodenext.

Actual Behavior

ts-node is resolving to the commonjs build of a dependency, even though tsc resolves to the esm build.

Steps to reproduce the problem

Using the reproduction below, notice:

11:34:45 {master} ~/ts-node-nodenext-bug$ npm install
11:35:13 {master} ~/ts-node-nodenext-bug$ npx tsc
11:35:28 (master) ~/ts-node-nodenext-bug$ node --loader ts-node/esm index.ts
(node:25884) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
/home/perrin4869/ts-node-nodenext-bug/node_modules/ts-node/src/index.ts:843
 return new TSError(diagnosticText, diagnosticCodes, diagnostics);
 ^
TSError: ⨯ Unable to compile TypeScript:
index.ts:3:7 - error TS2322: Type 'typeof import("/home/perrin4869/ts-node-nodenext-bug/foo/cjs/index")' is not assignable to type 'number'.

3 const bar: number = foo;
 ~~~

 at createTSError (/home/perrin4869/ts-node-nodenext-bug/node_modules/ts-node/src/index.ts:843:12)
 at reportTSError (/home/perrin4869/ts-node-nodenext-bug/node_modules/ts-node/src/index.ts:847:19)
 at getOutput (/home/perrin4869/ts-node-nodenext-bug/node_modules/ts-node/src/index.ts:1057:36)
 at Object.compile (/home/perrin4869/ts-node-nodenext-bug/node_modules/ts-node/src/index.ts:1411:41)
 at transformSource (/home/perrin4869/ts-node-nodenext-bug/node_modules/ts-node/src/esm.ts:400:37)
 at /home/perrin4869/ts-node-nodenext-bug/node_modules/ts-node/src/esm.ts:278:53
 at async addShortCircuitFlag (/home/perrin4869/ts-node-nodenext-bug/node_modules/ts-node/src/esm.ts:409:15)
 at async ESMLoader.load (node:internal/modules/esm/loader:407:20)
 at async ESMLoader.moduleProvider (node:internal/modules/esm/loader:326:11)
 at async link (node:internal/modules/esm/module_job:70:21) {
 diagnosticCodes: [ 2322 ]
}

I think this has to do with the fact that foo is using package.json with "type": "commonjs" to specify the commonjs build.
If this is changed to a cjs file, the problem does not occur

Minimal reproduction

https://github.com/perrin4869/ts-node-nodenext-bug

[cspotcode]

Thank you for the excellent reproduction.

As a workaround until a proper fix is made, you can add "transpileOnly": true to your tsconfig. It appears the runtime resolver hooks are working correctly, but the type-checker resolves incorrectly.

I tried adding "traceResolution": true to tsconfig so that I could see what typescript was logging as it discovered modules. It's strange, everything seems correct, except it doesn't explain how it decides to pick cjs vs esm. It just... picks wrong.

TSC output

❯ ./node_modules/.bin/tsc
...
======== Resolving module 'foo' from '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/index.ts'. ========
Module resolution kind is not specified, using 'NodeNext'.
File '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/package.json' exists according to earlier cached lookups.
Loading module 'foo' from 'node_modules' folder, target file type 'TypeScript'.
Found 'package.json' at '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/node_modules/foo/package.json'.
'package.json' does not have a 'typesVersions' field.
### NOTE this is the line where it chooses esm ###
File name '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/node_modules/foo/esm/index.js' has a '.js' extension - stripping it.
File '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/node_modules/foo/esm/index.ts' does not exist.
File '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/node_modules/foo/esm/index.tsx' does not exist.
File '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/node_modules/foo/esm/index.d.ts' exist - use it as a name resolution result.
Resolving real path for '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/node_modules/foo/esm/index.d.ts', result '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/foo/esm/index.d.ts'.
======== Module name 'foo' was successfully resolved to '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/foo/esm/index.d.ts'. ========

ts-node output

❯ node --loader ts-node/esm ./index.ts
...
======== Resolving module 'foo' from '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/index.ts'. ========
Module resolution kind is not specified, using 'NodeNext'.
Found 'package.json' at '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/package.json'.
'package.json' does not have a 'typesVersions' field.
Loading module 'foo' from 'node_modules' folder, target file type 'TypeScript'.
Found 'package.json' at '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/node_modules/foo/package.json'.
'package.json' does not have a 'typesVersions' field.
### NOTE this is the line where it chooses cjs. Why? ###
File name '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/node_modules/foo/cjs/index.js' has a '.js' extension - stripping it.
File '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/node_modules/foo/cjs/index.ts' does not exist.
File '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/node_modules/foo/cjs/index.tsx' does not exist.
File '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/node_modules/foo/cjs/index.d.ts' exist - use it as a name resolution result.
Resolving real path for '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/node_modules/foo/cjs/index.d.ts', result '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/foo/cjs/index.d.ts'.
======== Module name 'foo' was successfully resolved to '/d/Personal-dev/@TypeStrong/ts-node-repros/ts-node-nodenext-bug/foo/cjs/index.d.ts'. ========
...

[cspotcode]

I think I found the issue. To support the new NodeNext mode, TypeScript's resolver needs to pass around new information about the type of the module making the import request: either cjs or esm. That info is passed in new, optional arguments in some of the compiler APIs, so it wasn't flagged as an error when we moved to the new TS version. Should be a straightforward fix that I can do soon.

[cspotcode]

Note to self, how to fix this bug:

Update the signatures of these two functions to include the new, optional arguments in TS4.7
Do a sanity-check that these changes are fully backwards-compatible so that we continue to behave against older TS versions.

ts-node/src/resolver-functions.ts

Lines 87 to 131 in b3dd3f2

	/*
	* NOTE:
	* Older ts versions do not pass `redirectedReference` nor `options`.
	* We must pass `redirectedReference` to newer ts versions, but cannot rely on `options`, hence the weird argument name
	*/
	const resolveModuleNames: TSCommon.LanguageServiceHost['resolveModuleNames'] =
	(
	moduleNames: string[],
	containingFile: string,
	reusedNames: string[] | undefined,
	redirectedReference: TSCommon.ResolvedProjectReference | undefined,
	optionsOnlyWithNewerTsVersions: TSCommon.CompilerOptions
	): (TSCommon.ResolvedModule | undefined)[] => {
	return moduleNames.map((moduleName) => {
	const { resolvedModule } = ts.resolveModuleName(
	moduleName,
	containingFile,
	config.options,
	host,
	moduleResolutionCache,
	redirectedReference
	);
	if (resolvedModule) {
	fixupResolvedModule(resolvedModule);
	}
	return resolvedModule;
	});
	};
	// language service never calls this, but TS docs recommend that we implement it
	const getResolvedModuleWithFailedLookupLocationsFromCache: TSCommon.LanguageServiceHost['getResolvedModuleWithFailedLookupLocationsFromCache'] =
	(
	moduleName,
	containingFile
	): TSCommon.ResolvedModuleWithFailedLookupLocations | undefined => {
	const ret = ts.resolveModuleNameFromCache(
	moduleName,
	containingFile,
	moduleResolutionCache
	);
	if (ret && ret.resolvedModule) {
	fixupResolvedModule(ret.resolvedModule);
	}
	return ret;
	};

[perrin4869]

thank you so much for the quick response @cspotcode!

[perrin4869]

@cspotcode Thank you so much for the fix! Was just wondering if by any chance you could cut a 10.8.1, and leave #1764 for a 10.8.2 release? Just real eager to be using nodenext XD

[cspotcode]

Yeah, absolutely. I can do that tomorrow morning.

[cspotcode]

@perrin4869 v10.8.1 is published, thanks for your patience, and please let me know if you hit any other issues.

https://github.com/TypeStrong/ts-node/releases/tag/v10.8.1