In VSCode, monorepo's sub-packages should load @types/node which has been installed in their own node_modules

[zanminkian]

🔎 Search Terms

vscode monorepo load types

🕗 Version & Regression Information

• This is the behavior in every version I tried.

Let's say I hava a monorepo. There is a unit test file in a sub-package. If this unit test file cannot match any tsconfig.json in this monorepo, there will be some importing errors (eg import assert from "node:assert") in VSCode editor, even though it has already installed @types/node.

⏯ Playground Link

https://github.com/zanminkian/bug-report/tree/typescript/should_load_nearest_node_modules_types_bug

💻 Code

Please open https://github.com/zanminkian/bug-report/tree/typescript/should_load_nearest_node_modules_types_bug and read the readme to reproduce. Thanks.

Reproduce steps:

1. Clone this repo and checkout typescript/should_load_nearest_node_modules_types_bug branch.
2. Open this project using VSCode.
3. Run pnpm i in the root of this project.
4. Refresh VSCode (close all tabs).
5. Open ./packages/foo/src/foo.spec.ts file.

Some related codes:

// Root tsconfig.json
{
  "include": ["${configDir}/src"],
  "exclude": ["**/*.spec.ts","**/*.test.ts"],
  "compilerOptions": {
    "lib": ["ES2022"],
    "target": "ES2022",
    "module": "Node16",
    "moduleResolution": "node16",
    "outDir": "${configDir}/dist"
  }
}

// Sub-package tsconfig.json
{
  "extends": "../../tsconfig.json"
}

// Unit test file
import assert from "node:assert"; // There is a importing error here
import { describe, it } from "node:test"; // There is a importing error here
import { foo } from "./foo.js";

describe("foo", async () => {
  it("foo should be /foo/bar", () => {
    assert.strictEqual(foo, '/foo/bar')
  })
})

🙁 Actual behavior

See the screenshot above. There are some importing errors.

🙂 Expected behavior

No errors in VSCode.

Additional information about the issue

No response

[RyanCavanaugh]

We have no way to know that node:assert comes in from @types/node -- an ambiently-declared module like that could come from anywhere. You'd need to add

/// <reference types="node" />

to foo.spec.ts if you want the inferred project to load it

[zanminkian]

@RyanCavanaugh If we uninstall @types/node in the sub-package and then install it in the root, the importing errors disappear in foo.spec.ts. So I guess TypeScript load the ./node_modules/@types/node in the root, instead of sub-package when there is no tsconfig.json match foo.spec.ts.
When opening a *.spec.ts file in sub-package, if no tsconfig.json work for the *.spec.ts file, *.spec.ts file should load ./node_modules/@types/* in its own folder, while currently load ./node_modules/@types/* in the root.

[zanminkian]

Please open the screen shot above for detail. I think it's very inconvenient and counterintuitive if TypeScript load the `@types/node` in the project root `node_modules` instead of from the nearest `node_modules`.

Loading @types/node from the nearest node_modules or the node_modules close to the nearest tsconfig.json is like node module resolution. Seems reasonable.

[RyanCavanaugh]

We call it an inferred project for a reason - we can only guess at what you want to happen. We can guess differently but that's going to break different people with other scenarios, and they'll ask for the guess to change back to the current behavior.