Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeScript 3.7+ regression issue in Lerna monorepo w/ Yarn Workspaces and composite projects #35768

Closed
amirburbea opened this issue Dec 19, 2019 · 4 comments · Fixed by #35784
Assignees
Labels
Bug A bug in TypeScript Fix Available A PR has been opened for this issue

Comments

@amirburbea
Copy link

amirburbea commented Dec 19, 2019

TypeScript Version: 3.7.3

Node Version: 12.13.1

Search Terms: lerna, monorepo, yarn, workspaces

Problem Description:
TypeScript 3.7+ seems to have issues in a Lerna monorepo using yarn workspaces. TypeScript 3.6.4 does not exhibit the same problem. In the example repo (https://github.com/amirburbea/ts-37-issue), there are two projects @issue/utilities and @issues/server.

@issue/utilities is a typescript composite library. For the purpose of keeping it simple, this project exports a single default function - but I experienced this issue in a signficantly larger project with named exports.

@issue/server is a node application that invokes the function exported in @issue/utilities.

There are several scripts you can run at the root when testing which will save a great deal of time

  • yarn build: Instructs typescript to build the projects.
  • yarn clean: Instructs every project to delete their build outputs and tsconfig.tsbuildinfo
  • yarn rebuild: Runs clean and then build
  • yarn start: Runs build and then starts the output of @issue/server

In general, both in TypeScript 3.6.4 and TypeScript 3.7.3, the code will transpile and afterwards, run identically.

The issue is in the editing experience. If you build and then open the file packages/server/src/index.ts in VS Code, typescript initializes, and when that process is complete hovering over line 4 run(); will show that intellisense has an understanding of the exported function from @issue/utilities.

image

Now simply add a blank line at the end of the file - TypeScript will suddenly not understand the import of @issue/utilities (the import will have squiggly red lines under it and the type will be unknown) until I again reload the window making editing a painful experience. I experienced this in both Visual Studio Code 1.4.1.0 and Visual Studio 2019 16.4.2 almost identically.

image

I upgraded the two package.json to use typescript 3.8 daily build and got the same error. I downgrade them to use typescript 3.6.4 and the issue goes away.

As an FYI, my own project structure (which this example repo mirrors) is based on a sample posted by @DanielRosenwasser when composite was first introduced, but I'm happy to make changes to my tsconfig files if someone can suggest a workaround.

@amirburbea
Copy link
Author

Not only does lerna connect the references by a simlink, but the node_modules folder is at the repository root (and not at each project level) - I wonder if somehow that's what's breaking typescript.

@amirburbea amirburbea changed the title TypeScript 3.7+ issue with Lerna monorepo utilizing Yarn Workspaces and composite projects TypeScript 3.7+ regression issue with Lerna monorepo utilizing Yarn Workspaces and composite projects Dec 19, 2019
@amirburbea amirburbea changed the title TypeScript 3.7+ regression issue with Lerna monorepo utilizing Yarn Workspaces and composite projects TypeScript 3.7+ regression issue with Lerna monorepo w/ Yarn Workspaces and composite projects Dec 19, 2019
@amirburbea amirburbea changed the title TypeScript 3.7+ regression issue with Lerna monorepo w/ Yarn Workspaces and composite projects TypeScript 3.7+ regression issue in Lerna monorepo w/ Yarn Workspaces and composite projects Dec 19, 2019
@amirburbea
Copy link
Author

amirburbea commented Dec 19, 2019

Actually I'm able to get this to stop breaking with a workaround that says I should add a baseUrl and paths to the @issues/server tsconfig. I guess I'm willing to do that, but it seems unnecessarily verbose and was not required in typescript 3.6.4

{
  "compilerOptions": {
    "outDir": "lib",
    "rootDir": "src",
    "baseUrl": "../../",
    "paths": { "@issue/utilities": ["packages/utilities"] }
  },
  "exclude": ["./lib/", "./node_modules/"],
  "extends": "../tsconfig.base.json",
  "references": [{ "path": "../utilities" }]
}

@sheetalkamat sheetalkamat added the Needs Investigation This issue needs a team member to investigate its status. label Dec 19, 2019
@sheetalkamat sheetalkamat self-assigned this Dec 19, 2019
@sheetalkamat sheetalkamat added Bug A bug in TypeScript and removed Needs Investigation This issue needs a team member to investigate its status. labels Dec 19, 2019
@sheetalkamat
Copy link
Member

Note that this issue repros only when preserveSymlinks is set to true

@amirburbea
Copy link
Author

Does this mean that in TS3.8 this will work without me specifically putting in the baseUrl/paths?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript Fix Available A PR has been opened for this issue
Projects
None yet
2 participants