Typing not being loaded correctly

[linde12]

Custom typings (own path in "typeRoots") are not being loaded when i'm using @mailchimp/mailchimp_marketing - they provide a types.d.ts file which only defines a OpenAPI namespace (and no module) so ts-node just errors saying that types.d.ts is not a module - tsc however also parses my custom typing and correctly identifies the module declaration from my custom index.d.ts file.

Expected Behavior

index.d.ts to be loaded even if there is a types.d.ts in node_modules/@mailchimp/mailchimp_marketing/

Actual Behavior

Only types.d.ts is loaded, the index.d.ts in my custom typings/ folder is ignored. Removing types.d.ts from node_modules/@mailchimp/mailchimp_marketing/ resolves the issue. tsc correctly resolves both types.d.ts and index.d.ts

Steps to reproduce the problem & minimal reproduction

Add a tsconfig with typeRoots specified as per https://github.com/TypeStrong/ts-node#help-my-types-are-missing and then do:

npm i @mailchimp/mailchimp_marketing # this package provides a types.d.ts but only defines a namespace, not declaring a module
mkdir -p typings/@mailchimp/mailchimp_marketing
echo "declare module '@mailchimp/mailchimp_marketing';" > typings/@mailchimp/mailchimp_marketing/index.d.ts
mkdir src
echo "import client from '@mailchimp/mailchimp_marketing'" > src/index.ts
./node_modules/.bin/ts-node src/index.ts # errors
./node_modules/.bin/tsc # compiles fine

Specifications

• ts-node version: 9.0.0
• node version: 14.15.1
• TypeScript version: 4.0.5
• tsconfig.json, if you're using one:

{
  "compilerOptions": {
    "target": "ES2020",                          /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018', 'ES2019', 'ES2020', or 'ESNEXT'. */
    "module": "commonjs",                     /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', 'es2020', or 'ESNext'. */
    "lib": ["ES2020"],                             /* Specify library files to be included in the compilation. */
    "outDir": "./build",                        /* Redirect output structure to the directory. */
    "moduleResolution": "node",            /* Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6). */
    "baseUrl": "src/",                       /* Base directory to resolve non-absolute module names. */
    "types": ["node"],                           /* Type declaration files to be included in compilation. */
    "esModuleInterop": true,                  /* Enables emit interoperability between CommonJS and ES Modules via creation of namespace objects for all imports. Implies 'allowSyntheticDefaultImports'. */
    "typeRoots": ["./typings", "./node_modules/@types"]
  }
}

• Operating system and version: Windows 10 (20H2)
• If Windows, are you using WSL or WSL2?: WSL2

[linde12]

FYI: Works fine with --files but i'd like to avoid it if possible.

[blakeembrey]

Does changing the directory name to mailchimp__mailchimp_marketing work? IIRC TypeScript looks for the directory the same way it would exist in node_modules, and you can't do @types/@mailchimp/mailchimp_marketing on NPM so they use the __ scheme.

[linde12]

Does changing the directory name to mailchimp__mailchimp_marketing work? IIRC TypeScript looks for the directory the same way it would exist in node_modules, and you can't do @types/@mailchimp/mailchimp_marketing on NPM so they use the __ scheme.

Ill try tomorrow and report back here - makes sense i guess, i didnt know about this rule Thanks! 😄

[cspotcode]

I bet if you set "rootDir": "src" it will also start failing in tsc. Which I know sounds like a weird suggestion; "why is he asking me to break it?"

But my hunch is that the typings are not actually being loaded via typeRoots / types. They are being loaded because ./typings/ is within your rootDir which defaults to .. tsc and ts-node --files eagerly load everything within rootDir. This informs it of your @mailchimp/mailchimp_marketing declaration, so it never attempts to pull the declaration from node_modules.

If my hunch is correct, adding a /// <reference path= above the import "@mailchimp/mailchimp_marketing" should fix this. /// <reference> is how you trigger file inclusion without --files.

[cspotcode]

I've used tsc --traceResolution to understand messy stuff like this. It spits out an extreme level of detail, but once you get the log into a text editor where you can search for the file you care about, it details exactly what tsc is doing. If Blake's correct and the directory needs to be renamed, I bet tsc --traceResolution will show tsc attempting to find that directory and failing.

[linde12]

I tried setting "rootDir": "src" but tsc still resolves it successfully. Here is a part of --traceResolution:

======== Resolving module '@mailchimp/mailchimp_marketing' from '/home/xyz/repo/src/index.ts'. ========
Explicitly specified module resolution kind: 'NodeJs'.
'baseUrl' option is set to '/home/xyz/repo/src', using this value to resolve non-relative module name '@mailchimp/mailchimp_marketing'.
Resolving module name '@mailchimp/mailchimp_marketing' relative to base url '/home/xyz/repo/src' - '/home/xyz/repo/src/@mailchimp/mailchimp_marketing'.
Loading module as file / folder, candidate module location '/home/xyz/repo/src/@mailchimp/mailchimp_marketing', target file type 'TypeScript'.
Loading module '@mailchimp/mailchimp_marketing' from 'node_modules' folder, target file type 'TypeScript'.
Directory '/home/xyz/repo/src/node_modules' does not exist, skipping all lookups in it.
Scoped package detected, looking in 'mailchimp__mailchimp_marketing'
Found 'package.json' at '/home/xyz/repo/node_modules/@mailchimp/mailchimp_marketing/package.json'.
'package.json' does not have a 'typesVersions' field.
File '/home/xyz/repo/node_modules/@mailchimp/mailchimp_marketing.ts' does not exist.
File '/home/xyz/repo/node_modules/@mailchimp/mailchimp_marketing.tsx' does not exist.
File '/home/xyz/repo/node_modules/@mailchimp/mailchimp_marketing.d.ts' does not exist.
'package.json' does not have a 'typings' field.
'package.json' has 'types' field 'types.d.ts' that references '/home/xyz/repo/node_modules/@mailchimp/mailchimp_marketing/types.d.ts'.
File '/home/xyz/repo/node_modules/@mailchimp/mailchimp_marketing/types.d.ts' exist - use it as a name resolution result.
Resolving real path for '/home/xyz/repo/node_modules/@mailchimp/mailchimp_marketing/types.d.ts', result '/home/xyz/repo/node_modules/@mailchimp/mailchimp_marketing/types.d.ts'.
======== Module name '@mailchimp/mailchimp_marketing' was successfully resolved to '/home/xyz/repo/node_modules/@mailchimp/mailchimp_marketing/types.d.ts' with Package ID '@mailchimp/mailchimp_marketing/types.d.ts@3.0.44'. ========

Looks like tsc is satisfied with the types.d.ts (containing only the empty OpenAPI namespace) - ts-node is failing, even after @blakeembrey suggestion with the folder name (i tried moving my definition to ./typings/mailchimp__mailchimp_marketing/index.d.ts)

EDIT: I removed my typings folder to see whether tsc really didnt care about it, but it does fail when i remove typings so i it is looking at the typings folder but --traceResolution isn't mentioning anything about it.

[linde12]

The only thing i've gotten to work was the <reference> comment or the --files flag, but neither are ideal. The reference comment will cause confusion for people who don't know what it is and they might remove it. Also (i dont know if this is the case but..) i dont want to add it everywhere this module is being imported.

The --files is a workaround for now but it makes compilation considerably slower to the point where i might as well use tsc and incremental builds.

[blakeembrey]

Have you tried using paths? I forgot in the original issue, but typeRoots is only for the “global” modules to get automatically picked up while paths is used during resolution.

[cspotcode]

This works:
https://github.com/TypeStrong/ts-node-repros/tree/1362

Here are the logs:
https://github.com/TypeStrong/ts-node-repros/runs/2749033303

[cspotcode]

Blake's suggestion also sounds smart; but I wanted to offer a backup.