microsoft / microsoft/TypeScript

Optimal TS monorepos: how to handle project references when projects opt out of composite within dependency chain

Open
#59,727 4 comments 0 reactions 1 assignee View on GitHub

@sheetalkamat is already working on this.

Since Sep 6, 2024.

Needs Investigation
Dominant language
Go
Stars
111k
Forks
14.3k
Avg merge
1d 19h
Merged PRs (30d)
117

Description

πŸ”Ž Search Terms

project references
no output

πŸ•— Version & Regression Information

N/A

⏯ Playground Link

N/A

πŸ’» Code
// Your code here
πŸ™ Actual behavior

Please see full description, repro and video walkthrough

πŸ™‚ Expected behavior

Please see full description, repro and video walkthrough

Additional information about the issue

I am reporting this as an issue because @jakebailey advised me that that would make sense for any time a Debug Error is reached in TS, but also to get formal guidance from the TS Team on finalizing our new TypeScript plugin for Nx.

As discussed in our sync between our teams a couple of months ago, we are building a new mechanism to sync Nx project graph (derived from package.json files and import and export statements) automatically to configuration files on disk. This is a generic mechanism, but in the context of TS, this applies to syncing project references in tsconfig.json files.

This should allow us to keep Nx out of the way of tsc where appropriate (tsc will be directly executed by Nx behind the scenes when using nx typecheck my-ts-proj or nx build my-ts-proj for example) and still allow users to run raw tsc if they wish because all the relevant config will live on disk and be up to date thanks to Nx.

The syncing mechanism is working really well already for repo's which can fully stick to composite: true throughout the codebase, but we have already run into one case on the https://github.com/typescript-eslint/typescript-eslint (where @jakebailey and @sheetalkamat kindly help out) where a couple of projects needed to opt out of composite: true and not emit declaration files at all.

As explained in detail in attached loom covering the reproduction repo, we would like some advice on how we should attempt to handle cases like this in our syncing logic.

The super brief summary of the issue causing it to hit the Debug Failure is:

  • Projects: A -> B -> C
  • B is opting out of composite
  • The root solution file can happily reference all 3 projects as hoped, despite the composite opt out of B
  • We want to be able to typecheck A, B and C
  • tsc -b --emitDeclarationOnly is used for typechecking (intentionally kept distinct from building with tsc, producing JS artifacts)
  • When typechecking the whole repo, or typechecking just A, we hit the Debug failure because of B not having any outputs before proceeding onto A

πŸŽ₯ Context and issue reproduction: https://www.loom.com/share/84a7098b3d1e4a819bd598ad7fc3ae7f

πŸ”— Reproduction repo: https://github.com/JamesHenry/tsc-composite-false-repro

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up β€” it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.