TypeScript fails to resolve dependency in monorepo given specific conditions

[remcohaszing]

🔎 Search Terms

"composite references"

🕗 Version & Regression Information

• This changed between versions 4.6 and 4.7 (by introducing module option nodenext).

⏯ Playground Link

https://github.com/remcohaszing/typescript-bug

💻 Code

Since this bug is about resolving imports in a mono repo and composite project references, it requires more than one file.

package.json: defines workspaces.

{
  "private": true,
  "workspaces": [
    "packages/*"
  ],
  "dependencies": {
    "typescript": "5.3.3"
  }
}

packages/a/package.json defines the dependant project

{
  "name": "a",
  "version": "0.0.0",
  "type": "module",
  "exports": {
    ".": {
      "types": "./types/index.d.ts",
      "default": "./index.js"
    }
  }
}

packages/a/tsconfig.json declares the referenced TypeScript project. It uses types in JSDoc and emits the types definitions into the types directory.

{
  "compilerOptions": {
    "checkJs": true,
    "composite": true,
    "declaration": true,
    "emitDeclarationOnly": true,
    "module": "nodenext",
    "outDir": "types"
  }
}

packages/a/index.js must exist. This is what can’t be resolved. The contents don’t matter.

// Empty

packages/a/test/index.js imports a. This file must be in a subdirectory of the a project for the bug to appear.

import 'a'

packages/b/package.json defines the project that depends on a.

{
  "name": "b",
  "version": "0.0.0",
  "type": "module"
}

packages/b/tsconfig.json declares the TypeScript project that references a. It uses types in JSDoc and doesn’t emit (but that’t irrelevant). Important is the noImplicitAny option. Disabling it, makes the bug go away.

{
  "references": [{"path": "../a"}],
  "compilerOptions": {
    "checkJs": true,
    "module": "nodenext",
    "noEmit": true,
    "noImplicitAny": true
  }
}

packages/b/index.js dynamically imports a. A static import won’t make the bug appear.

import('a')

Now build project b by running tsc --build packages/b.

🙁 Actual behavior

TypeScript builds a as it’s a referenced by b. It then errors with the following output:

packages/b/index.js:1:8 - error TS7016: Could not find a declaration file for module 'a'. 'references/packages/a/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/a` if it exists or add a new declaration (.d.ts) file containing `declare module 'a';`

1 import('a')
         ~~~


Found 1 error.

Running the same command again builds project b.

🙂 Expected behavior

TypeScript builds project a, then b.

Additional information about the issue

No response

[RyanCavanaugh]

It looks like you're using a package manager that doesn't set up symlinks, so TS has no way to know that you have the outer monorepo setup, thus doesn't have any way to know that packages/ is where you can find a. The easiest way is to address that is to just add a baseUrl:

    "baseUrl": "../"

[remcohaszing]

I see I forgot to specify you have to run npm install, but I did do this in my testing. This creates symlinks.

I forgot that TypeScript doesn’t validate bare import specifiers, but it does check dynamic imports. Apart from that the difference between an import statement or an import declaration doesn’t matter. I updated the example repo to make b export something from a. This also makes the error appear.

This made me suspicious, because in my real world code one workspace does have this problem, but another doesn’t. It turns out enabling resolveJsonModule in the dependant module (b) makes the error go away, even though there are no JSON imports anywhere. I added a this option, commented, so it can be toggled easily.

baseUrl doesn’t solve the problem, because the real world example uses scoped packages. This can be solved using paths, but I don’t think that should be necessary.

[RyanCavanaugh]

Something's gone wrong here; tsc -b -f b fails but tsc -p b does not

[remcohaszing]

Apparently the workaround of enabling resolveJsonModule only works if this is enabled in the configuration file of b directly, not if it’s enabled in a configuration it extends from.

[fatcerberus]

Apparently the workaround of enabling resolveJsonModule only works if this is enabled in the configuration file of b directly, not if it’s enabled in a configuration it extends from.

That sounds like a bug - if you can repro it, you should report that in a separate issue.