Use customConditions to support project reference correctly in a monorepo

[Jack-Works]

Bug Report

I cannot use customConditions to redirect a monorepo package to its source.

Background

TypeScript project reference requires manually declaring all referenced projects.

For example, we have 2 projects app and lib under /projects/app and /projects/lib and app depends on lib, if we do not list lib in the references, when we write

/packages/app/src/index.ts

import { something } from '../../lib'

If there is no "reference": [{ "path": "../lib/tsconfig.json" }] in /packages/app/tsconfig.json,
TypeScript will complain TS6307: "File '/packages/lib/src/index.ts' is not listed within the file list of the project '/packages/app/tsconfig.json'. Projects must list all files or use an 'include' pattern."

This error is GOOD because it means TypeScript can detect the missing references, you just need to add them manually.

What about monorepo? This is where things start to get wrong.

Here is an example. example-1-no-reference

TypeScript cannot detect the missing references when we install them as monorepo packages.

It still has the project structure above, but lib is installed as "@test-a/lib" in /packages/lib/node_modules/@test-a/lib, TypeScript accepts the missing reference to the lib project,
because it will go through the "moduleResolution": "NodeNext" resolution.

If a .d.ts file is found (this usually happens when you have a previous build), the project will accidentally compile, but TypeScript DOESN'T know it should be a project reference. It causes the project randomly fail to be type-checked.

Old solution

example-2-path

We use the the "paths" field to map the Node-style import back to the relative one,
therefore TypeScript can check the missing dependencies again.

This is a working solution, BUT with 2 new problems:

• The "paths" list needs manually maintain, and easy to get desync with the package.json/exports
• Now we can use a monorepo dependency without installing it in the package manager,
  which is unwanted.

New solution?

Since #51669 brings the new compiler options --customConditions, I tried to use it to solve this problem without using "paths". This is what I get, it does not work I think TypeScript should fix this problem or provide a better solution to make project reference work with monorepo.

example-3-conditions

⏯ Playground Link

Jack-Works/typescript-use-customCondition-to-redirect-monorepo-source-to-support-project-reference

[RyanCavanaugh]

This isn't what customConditions is for. It's there to instruct TS about which entries in the export map are valid to consult during module resolution, no more, no less. It's possible you can use this to get partially down the road of setting up a monorepo, but it's not a replacement for setting up correct project references (or other valid monorepo configurations), isn't designed to do that, and is in fact designed for a completely orthogonal problem.

[Jack-Works]

but it's not a replacement for setting up correct project references

Yes I know, my intention here is to make TypeScript warn me when the project reference is not correctly set. I'm not hoping TypeScript can use the monorepo information to infer the project reference.

Please see example 1, TypeScript does not warn me in the monorepo (but it does for normal relative import).

This isn't what customConditions is for.

Is there any other solution to make this work?

[RyanCavanaugh]

We're effectively just talking about #25376, right?

[Jack-Works]

No, I'm not expecting TypeScript to infer that. But I want TypeScript warn me if I forgot to add it like I'm not using monorepo.

[fatcerberus]

How would TypeScript know it’s dealing with a monorepo as opposed to a regular project, if you didn’t already configure it as one?

[Jack-Works]

Because the @monorepo-pkg/name is a symlink and resolved to a position outside of a node_modules folder

[typescript-bot]

This issue has been marked as "Declined" and has seen no recent activity. It has been automatically closed for house-keeping purposes.