Issue in generated tsconfig files for apps & libs

[johannesschobel]

Current Behavior

Yesterday, i noticed a strange behavior when working in my newly (!) created nrwl workspace. I develop with the latest VSCode (1.52.x) and was not able to "update imports on file move" anymore (i.e., update the import statements when moving a file).

This issue #3106 is somewhat related to my problem

Expected Behavior

It should be able to update the import statements. This was able in prior versions of nrwl, but i don't know how many versions we need to go back.

Steps to Reproduce

I did a lot of investigations, but here is what i already found out to (at least for me) successfully reproduce the issue:

1. npx create-nx-workspace@latest foo (this should install version 11.1.x)
2. select an empty project
3. add a file a.ts and b.ts to the apps folder. Import b into a and then move b to another folder. this should work and the import statements should get properly updated 🟢
4. now add a library with npx nx generate @nrwl/workspace:lib bar
5. again, create a file a.ts and b.ts within this newly created lib and import b within a. Then move b, however, the import is not updated 🔴
6. this now also fails for the files created in step 3 (within the apps directory!)
7. now go to the libs/bar/tsconfig.json file and remove the includes and files attribute.
8. now go to the libs/bar/tsconfig.lib.json and libs/bar/tsconfig.spec.json and add a composite: true and declaration: true attribute to the compilerOptions.
9. save everything and try to move files again - it should now work again as expected 🟢

Environment

I use the latest version of nrwl/nx

[johannesschobel]

ok, i digged a bit deeper.. the proposed solution does not work, because it breaks tests and building apps.. Unfortunately, i was not able to find a proper solution (yet) that allows building the app, testing and refactoring in VSCode..

note that i also tried with a clean (!) and new installation with VSCode without any extensions in order to be sure it is not an issue with 3rd party packages!

[johannesschobel]

I really believe that the tsconfig.json references attribute is not correct here.
See the official docs ( https://www.typescriptlang.org/docs/handbook/project-references.html ) for more details:

Referenced projects must have the new composite setting enabled. This setting is needed to ensure TypeScript can quickly determine where to find the outputs of the referenced project. Enabling the composite flag changes a few things:

• The rootDir setting, if not explicitly set, defaults to the directory containing the tsconfig file
• All implementation files must be matched by an include pattern or listed in the files array. If this constraint is violated, tsc will inform you which files weren’t specified
• declaration must be turned on

The main tsconfig.base.json file, however, explicitly sets declaration to false, furthermore, the composite flag is missing in the referenced projects.

[johannesschobel]

ok.. i found a dirty workaround for my issue. I had an old workspace where everthing works as expected.
I checked the differences between the those workspaces and found some changes in the tsconfig files, as highlighted below.

I did the following things:

1. change every library tsconfig.json to this:

{
{
  "extends": "../../../tsconfig.base.json",
-  "files": [],
+  "include": ["**/*.ts"],
  "references": [
    { "path": "./tsconfig.lib.json" },
    { "path": "./tsconfig.spec.json" }
  ]
}

2. change every application tsconfig.json to this:

{
  "extends": "../../tsconfig.base.json",
-  "files": [],
+  "include": ["**/*.ts"],
  "references": [
    { "path": "./tsconfig.app.json" },
    { "path": "./tsconfig.spec.json" }
  ]
}

3. Restart VSCode and try to move a file

I don't know, what this workaround actually breaks, however, so far, it works better than the originally suggested approach!
Maybe someone from Team Nrwl can take a look at this and suggest a better (?) solution? It would be very appreciated!

Thank you very much!

[FrozenPandaz]

I was able to reproduce this issue. This is odd indeed.

From what I understand, "Solution" tsconfig.json files allow tsconfig.json to delegate out to different tsconfigs. Editors, this means that instead of every file within a directory being type-checked by tsconfig.json, they can now be type-checked by the first referenced tsconfig. This is particularly useful where different files within a directory are built with different tsconfig files which can have different compilerOptions such as the types that are available etc.. Utilizing this allows the compilation to be safer and less error-prone because it is no longer possible use jest types such as describe in your runtime code. I believe this is a good trade-off to take because the applications we ship are more robust because of it.

Now because different files can use different tsconfig files for type-checking, I imagine VSCode is unable to "reuse" the same program? In theory, this was also possible before if you moved a file to outside the library though I guess I didn't expect it to work because I understand it's complex.

I am able to achieve this behavior "automatically" in a sequence of steps in certain conditions (I know, bear with me) via the following:

1. Rename a file
2. In files where things are imported from that file, remove the import
3. Automatically import "Add all missing imports" as a fix for somewhere that isn't imported at the moment.
4. VSCode will add the import to the new file.

So obviously, this doesn't work in all scenarios .e.g. when files are re-exported and it's not always able to add all missing imports but I think it shows that VSCode could handle those particular conditions.

Thus, I think this might actually be a bug in vs code so I suggest reporting it there.

Also FWIW, Webstorm is able to automatically update the imports when doing the same file move. Not to say that you should switch but to say that this editor functionality is theoretically possible.

[johannesschobel]

Dear @FrozenPandaz ,
damn, i am actually very glad you could reproduce this issue.
I also played around with the solution file, however, just the solution file alone did not solve the issue for me.

I guess, WebStorm uses a different approach for finding / refactoring files than VSCode is.. However, due to the fact, that VSCode is free to use, and has nowadays a very large userbase, this issue should be addressed by nrwl.

Actually, i dont think that this is a bug in VSCode. The functionality was there in nrwl/nx 8 (or 9?) and it is a regression for later versions. Also, bootstrapping a plain nestjs application (without nrwl/nx) also works as intended..

All the best and thank you very (!) very much!
Johannes

[christianacca]

This is a long shot, but I have noticed that in earlier version of nx, library included references used to be added to tsconfig.app.json:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "../../dist/out-tsc",
    "types": []
  },
  "files": ["src/main.ts", "src/polyfills.ts"],
  "include": [
    "**/*.d.ts",
    "../../libs/your-lib/src/index.ts",
    "../../libs/your-other-lib/src/index.ts"
  ]
}

You see an example of this in the nrwl/nx-examples here

These references are no longer created with newer releases of nx, at least not for my workspace.

Maybe not having these includes causes VSC to no longer follow the dependency chain looking for import's to refactor?

[github-actions]

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
If we missed this issue please reply to keep it active.
Thanks for being a part of the Nx community! 🙏

[johannesschobel]

unstall this issue ;)

[hiepxanh]

it's a bug, so we keep it active

[JakeGinnivan]

I wrote up a blog post about how to setup typescript project references with NX. https://jakeginnivan.medium.com/using-typescript-project-references-in-nx-b3462b2fe6d4

[asbrum]

Still existing in Nx 12.x, any progress on this?

[johannesschobel]

Dear @FrozenPandaz ,

i know, you nx guys may be very busy because of your conference, but this issue is a real road block for larger projects. may you distribute this issue to someone who may be able to work on the latter? Maybe the solution provided by @JakeGinnivan is suitable and can be incorporated somehow!?

All the best and thanks for your awesome work!
Johannes

[effinrich]

Dear @FrozenPandaz and whomever else,
I just watched my 4 library, 3 app Nx monorepo fall apart in a couple of hours due to this nasty bug. As soon as it seems fixed, I get a ticker of new errors filing up my consoles. I'm going to have to attempt to take video of a section of interaction with it and try to pass it off as the POC i was to live demo for GM on Tuesday. Just slightly embarrassing fellas, not to mention my CTO might need to adjust my role to not working there. HUGE, show stopping, career smashing bug. Confused as to how it was even missed.

[gioragutt]

Any update on this? So far this has not caused me any problems other than files being shown with errors in the file explorer in vscode, but this should definitely be fixed.

This is, based on the error message, incorrect usage of typescript 🤷🏻‍♂️

[jahglow]

It actually does cause problems when you're trying to get the typescript work in watch mode - it disrespects imported libs

[dandouglas]

This issue still exists. Any news?

To note I am on the latest versions (13.3.1).

[duro]

I too am still seeing this issue

[SteffenAnders]

same, any updates here?

[johannesschobel]

i think this issue is still present in v14.x, right? Anyone from the nrwl team eager to look into this issue? ;) That would be awesome!

[normtronics]

@FrozenPandaz Any update on this?

[ymc9]

Same here with a relatively new project

[jedihacks]

Still alive!

[wSedlacek]

100% agreed. Well, maybe 99%. Not generating any project references would be an equally valid resolution, since Nx claims they don't use the tsconfig anyway. As things are now, nx does half the work, leaving the project in a broken state.

@FrozenPandaz (or anyone on the Nx team)
Having an option to generate libraries without the project references would be a huge step into solving this problem I think. Even if it is just an option that is disabled by default workspaces can opt into it via setting their defaults for generators in nx.json

Are there any blockers preventing this option from being added? I would be happy to work on a PR if this direction can be agreed upon.

[svallory]

Our workspace is even more volatile than this as we work in R&D and rapidly evolving and adding new features to products.

Thank you for clarifying. In that scenario, I think a single line possible conflict would be the least of my worries though 😂

On an unrelated note: You may want to take a look at https://graphite.dev (if you haven't already) it's a layer on top of git that helps a lot in cases like yours

[dylanwoodconsulting]

Just to clarify on how to reproduce this error (in VSCode), just add a file to the project. To get rid of it, just go to the tsconfig.json of the project (without making changes) and hit save. It's not a solution I like, but it isn't mysterious on how to cause it/get it to go away.

[wSedlacek]

@dylanwoodconsulting Pro Tip: You can also use "TypeScript: Restart TS Server" or "Developer: Reload Window" in the command pallet to reset errors like must have setting "composite": true".

The issue for my team is not the mostly harmless errors that show up in the editor, we have been living with those for 2 years. It is that with this configurations VS Code seems to slow down as you navigate between different projects. Our codebase is now up to 186 projects. In the current configuration there would be 186 TS Servers if you navigated to every single file (well actually more like 160 since some of the projects are not TypeScript). Having this many TS Servers running in the background seems to cause significant slow down in the editor.

We have been testing a "solutionless" style without using the generators and this has improved things. The initial startup time of the TS Server is slightly longer and memory usage for our 200k lines of TypeScript is about 2Gb, but it doesn't hit the point of slow down and there isn't new startup times every time you open a new project which has been a significant improvement for us.

[tirthaguha]

Well, at least this is less complex workaround. 👍

@dylanwoodconsulting Pro Tip: You can also use "TypeScript: Restart TS Server" or "Developer: Reload Window" in the command pallet to reset errors like must have setting "composite": true".

The issue for my team is not the mostly harmless errors that show up in the editor, we have been living with those for 2 years. It is that with this configurations VS Code seems to slow down as you navigate between different projects. Our codebase is now up to 186 projects. In the current configuration there would be 186 TS Servers if you navigated to every single file (well actually more like 160 since some of the projects are not TypeScript). Having this many TS Servers running in the background seems to cause significant slow down in the editor.

We have been testing a "solutionless" style without using the generators and this has improved things. The initial startup time of the TS Server is slightly longer and memory usage for our 200k lines of TypeScript is about 2Gb, but it doesn't hit the point of slow down and there isn't new startup times every time you open a new project which has been a significant improvement for us.

[jousby]

@FrozenPandaz Is this issue really blocked by third party?

My understanding after reading through all this:

• Nx currently generates packages/lib/apps that have tsconfig files with references in them.
• Those referenced tsconfig files do not have 'composite': true which the typescript doco says is needed.
• VSCode correctly reports that the referenced files don't have 'composite': true

It seems like the options for moving forward here both require NX doing an overhaul of how tsconfig is generated (not VSCode turning off the error). Either:

• NX generates configs that don't use references (as per @wSedlacek link above
  OR
• NX generates configs that correctly use references with the composite setting (as per the sevenwestmedia approach)

Simiilar to @wSedlacek we have been using NX for 18 months and have been tolerating the tsconfig files flagging errors in VSCode. I'm now considering try to adopt the approach used by sevenwestmedia in their plugins but would really prefer that NX have a solution for this and the default experience for Typescript projects is error free.

[dinosaurawr]

I was able to get rid of the error by installing vscode setting:

{
  "typescript.tsdk": "./node_modules/typescript/lib"
}

This may not solve the problem at the root, but it helps get rid of annoying errors

[Isaak-Marcel]

How has NX not fixed this 🤦‍♂️

[master96]

We have recently started using NX for tooling in our monorepo and I am in the process of migrating our Yarn workspace to an NX monorepo. I have a few questions and would appreciate some guidance:

1. I've noticed that VSCode sometimes struggles with the 15 libraries we have.
2. Could this be due to incorrect project configuration? The error messages suggest that something might not be configured correctly.

I have tried to follow the conversation above, but I need a bit of help to decide on the best approach as we are still early in the process and can make changes if necessary.

1. Should I ignore the errors and keep saving tsconfig whenever I encounter this issue?
2. If we adopt the nx-typescript-project-references approach based on @svallory 's comment above, does this mean we can't use other generators at all?
3. What are the downsides of adding composite: true? Why hasn't the NX team included this in the generators by default? Am I missing something here?

Thank you in advance for any help you can provide!

[lukket]

We could solve this issue by telling VS Code to use our workspace's TypeScript version (5.2.2). By default, VS Code seems to use its own TypeScript version and not the version of the current project you're working on.

As @dinosaurawr mentioned before, you can change this behavior in the settings. We added the following to our workspace's VS Code settings in .vscode/settings.json.

"typescript.tsdk": "[PATH_TO_NODE_MODULES_FOLDER]/typescript/lib"

After that, we had to open a TypeScript file of our project and explicitly choose the workspace's TypeScript version.

1. 
2. 

VS Code then seems to remember that choice and all the issue described here since two years were gone.

[master96]

@lukket I have the same settings as you mentioned, but I can still see issues in the tsconfig.json file.

Note: Saving the tsconfig.json file makes the error go away.

[lukket]

@master96 did you click on Select Version and then chose Use Workspace Version? The TypeScript version 5.5.4 in your screenshot seems to be VS Code's version that indeed displays the errors. Make sure the TypeScript version is the same as the TypeScript version in your package.json. In my case, it was 5.2.2 (see my screenshots).

[master96]

@master96 did you click on Select Version and then chose Use Workspace Version? The TypeScript version 5.5.4 in your screenshot seems to be VS Code's version that indeed displays the errors. Make sure the TypeScript version is the same as the TypeScript version in your package.json. In my case, it was 5.2.2 (see my screenshots).

Hey,
Sorry for confusion i have same version of typescript both in vscode and workspace 5.5.4. We upgraded version recently if you try 5.5.4 you might see same error again ? Not sure.

[lukket]

@master96 then of course my solution cannot work for you. With 5.5.4 I also get the errors.

[svallory]

We have recently started using NX for tooling in our monorepo and I am in the process of migrating our Yarn workspace to an NX monorepo. I have a few questions and would appreciate some guidance:

I'm sorry for your loss 🥺 (of the hours you'll still loose)

1. I've noticed that VSCode sometimes struggles with the 15 libraries we have.

That's what happen when you force typescript to compile everything, every time.

2. Could this be due to incorrect project configuration? The error messages suggest that something might not be configured correctly.

Not exactly. It's not the error that is causing tsc to slow down. It's the fact that it has no way (supposing you are using nx's default config) to reuse build information.

I have tried to follow the conversation above, but I need a bit of help to decide on the best approach as we are still early in the process and can make changes if necessary.

1. Should I ignore the errors and keep saving tsconfig whenever I encounter this issue?

That's easier then ignoring the slow build, but I still couldn't do it LOL

2. If we adopt the nx-typescript-project-references approach based on @svallory 's comment above, does this mean we can't use other generators at all?

No. In my experience, you'll have issues with the generators either way. I tried to use them multiple times, but there were always some config in my project that wasn't exactly the way the generator wanted and it would blow up.

3. What are the downsides of adding composite: true? Why hasn't the NX team included this in the generators by default? Am I missing something here?

The composite: true setting comes with some requriments. They may or may not affect your process. But in essence, you'll have to care about rootDir, include file patterns, and have emitDeclaration: true (this last one is kinda obvious though. How would you reference the compilation result without the compilation result, right?)

Thank you in advance for any help you can provide!

I think the only thing you are missing is that this kind of issue is everywhere. Regardless of your choice, if this issue has been unresolved since 2021, you can only imagine what else was left behind in favor of a "new version" to make a video about on youtube.

I appreciate that it took a lot of effort to create Nx, and that it's free and open-source, and I'm sure there are a lot of smart people working on it. But I also feel the need to warn people that arrive at this specific situation o the danger ahead. I've wasted weeks (yes, weeks, if not months) across 3 companies, dealing with nx issues. I don't want other people to go through that.

I'm sure nx works in a LOT of cases, for a LOT of projects. But if you found yourself at the end of this 3.5 YEARS OLD issue, my only advice for you is: use @moonrepo moon . I am NOT, in any way affiliated with them. I just switched about a year+ ago and never looked back, so I'm spreading the happiness.

PS: I'm turning off this issues notifications because I feel said every time I look at it.

All the best to you guys!

[WCN-llc]

As far as I understand NX console just helps to get quick access to commands and does not affect development, build, testing, etc.

Yes, NX console helps to create a structure quickly.
I created a structure using NX console, an error appeared in tsconfig.json (composite: true) and ... I just disabled NX console.
The error disappeared.
What are your opinions?

[WonderPanda]

As far as I understand NX console just helps to get quick access to commands and does not affect development, build, testing, etc.

Yes, NX console helps to create a structure quickly. I created a structure using NX console, an error appeared in tsconfig.json (composite: true) and ... I just disabled NX console. The error disappeared. What are your opinions?

The fact that the error disappeared after you disabled the Console is just a coincidence. The issue is with the actual Typescript config files and not being properly set up for project references + composite. Even without using the console at all this has been an issue for several years now

[WCN-llc]

As far as I understand NX console just helps to get quick access to commands and does not affect development, build, testing, etc.
Yes, NX console helps to create a structure quickly. I created a structure using NX console, an error appeared in tsconfig.json (composite: true) and ... I just disabled NX console. The error disappeared. What are your opinions?

The fact that the error disappeared after you disabled the Console is just a coincidence. The issue is with the actual Typescript config files and not being properly set up for project references + composite. Even without using the console at all this has been an issue for several years now

Let's see... If there will be an error when NX console is disabled, I will write. For now I assume that there is a code in the console code that overrides project settings.

[tushar-singh]

I've been following this thread for a while and this was one of the worst aspects of Nx for me
Looks like Nx 20 finally supports TS references natively!

https://nx.dev/blog/announcing-nx-20#typescript-project-references-for-monorepos

No migration path yet but I'm very excited about the efficiency & performance gains in large typescript projects

[hackmajoris]

In my case, it was because I overrode the paths array in the extended tsconfig files. Nx adds libraries to the paths attribute in the base tsconfig

[jedihacks]

Yeah we've been having this issue too - bump!

[zakwear]

Same.

[moatorres]

I've been using NX since v7 and I can guarantee you that it runs MUCH better with TS Project references with PNPM Workspaces. Let me know if you need any help migrating. I've learned the hard way, by choice, and would be glad to share the lessons learned.

[WonderPanda]

I've been using NX since v7 and I can guarantee you that it runs MUCH better with TS Project references with PNPM Workspaces. Let me know if you need any help migrating. I've learned the hard way, by choice, and would be glad to share the lessons learned.

I'd be very interested in the setup you've landed on based on all your learnings/experiences. I'm curious, when you say it runs much better what dimension are you referring to? Are you seeing improved typechecking speed across the monorepo? What else works better when you leverage this setup? I'd be very excited to see a blog post about this!

[moatorres]

I'd be very interested in the setup you've landed on based on all your learnings/experiences. I'm curious, when you say it runs much better what dimension are you referring to? Are you seeing improved typechecking speed across the monorepo? What else works better when you leverage this setup? I'd be very excited to see a blog post about this!

You nailed it. Smooth type checking and improved IDE response in general. Re: the blog post, challenge invitation accepted! Dare I say by Friday, 28?

[moatorres]

Appreciate your patience! Can’t wait to share it with you all.

[rtrembecky]

thanks for the update. patiently waiting 🙂

[moatorres]

Thank you for joining the thread, @rtrembecky. It should be out today, @WonderPanda. 🙏

[moatorres]

I've been using NX since v7 and I can guarantee you that it runs MUCH better with TS Project references with PNPM Workspaces. Let me know if you need any help migrating. I've learned the hard way, by choice, and would be glad to share the lessons learned.

I'd be very interested in the setup you've landed on based on all your learnings/experiences. I'm curious, when you say it runs much better what dimension are you referring to? Are you seeing improved typechecking speed across the monorepo? What else works better when you leverage this setup? I'd be very excited to see a blog post about this!

It ended up being longer than I initially expected, so there’s a chance it might continue in a follow-up. But for now, part 1 is finally live.

Edits
Beginner-friendly walkthrough on how to decompose libraries into modular packages, configure TailwindCSS v4 in a monorepo, and create Nx workspace plugins: part 2 is live.