TypeScript: Declarations are unexpectedly used from node_modules in parent directory

TypeScript Version: 3.4.0-dev.20190227 Search Terms: nested node_modules module resolution

I have a project nested inside another project. Both package.jsons import the same library, but they are two different versions of the library.

Issue In the files inside the inner project, I am able to import something that is only exported by the version of the library used by the outer project. When I open just the inner project in VSCode, I see two entries in the import intellisense for each export from the shared library, one from each version. It appears that Typescript is recursing up the directory tree, looking for node_modules and merging their declarations even through the library is already installed in the local node_modules.

Code

Here’s the import that should fail. I should only be able to import from "fp-ts/lib/HKT" here:

https://github.com/leemhenson/fp-ts-oom-repro/blob/master/subproject/user.ts#L2

Here’s the inner project’s import of the library:

https://github.com/leemhenson/fp-ts-oom-repro/blob/master/subproject/package.json#L7

Here’s the outer project’s import of the library:

https://github.com/leemhenson/fp-ts-oom-repro/blob/master/package.json#L8

I’ve tried settings types: [] and typeRoots, exclude: ["../node_modules"] etc.

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 9
Comments: 19 (4 by maintainers)

Most upvoted comments

 "compilerOptions": {
       "types" : []
   }

Will do the job.

Will not do the job (fully). You should read documentation for typeRoots and types. It only works for global modules, not imported. For imported modules, you have to use paths and baseUrl.

Either the docs are not correct, I did not understand them, or there is bug, because using it does not seem to restrict module resolution.

I have the following set in an inner project’s tsconfig.json:

{
  "compilerOptions": {
    "strict": true,
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "lib": ["dom", "es2017"],
    "jsx": "react",
    "typeRoots": ["./node_modules/@types"],
    "baseUrl": ".",
    "paths": {
      "*": ["./node_modules/*"]
    }
  },
  "include": ["src"]
}

Packages from parent/node_modules are still resolved.

Used typescript 3.7.4.

akomm on Jan 10, 2020

I have the same problem. what I think is happening is that:

node_modules/typescript/lib/typesMap.json

has an entry for ‘md5’ (and other things) and it’s using the parent mode_modules for resolving it.

I then get a ton of other associated errors due to module differences.

I tried changing typeRoots, exclude, and paths and none of them work. The documentation is incorrect that parent directories will not be used.

The only work around I’ve found is to move the parent node_modules out of the way.

The root cause is that typescript tries to pull it’s own things in which I didn’t specify and there’s no way to disable this or tell it to not load from …/node_modules

burtonator on Apr 30, 2019

These errors look to be coming from a third-party tool (tsl?), not TypeScript.

rbuckton on Jan 5, 2023

My comment was intended to serve as proof that node still navigates up when a part of a package sub-directory isn’t found.

I don’t know what Node is doing, but what TypeScript is doing doesn’t seem right. In my case it’s trying to parse type files and fails with errors like this:

ERROR in /packages/app-cli/node_modules/@types/jest/index.d.ts
[tsl] ERROR in /packages/app-cli/node_modules/@types/jest/index.d.ts(462,62)
      TS1005: ']' expected.

ERROR in /packages/app-cli/node_modules/@types/jest/index.d.ts
[tsl] ERROR in /packages/app-cli/node_modules/@types/jest/index.d.ts(462,65)
      TS1005: ';' expected.

I can’t make any sense of these errors, but more importantly why should I care that TypeScript can’t parse files that aren’t even used by my project? If I move said project to a different place with no parent node_modules, it works just fine.

Assuming this is, anyway, the right way to load packages (also it feels very wrong), at least there should be a clear options to disable this behaviour.

laurent22 on Jan 5, 2023