nx: Cannot find all references to shared lib's interfaces in VS Code

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

I was following the tutorial from nx docs and vscode not recognize @myorg/data shared lib, someone had this issue?

Thanks!

All this modern web-development is pretty sad. On real world project with dozen apps and 50 shared libs VScode is basically acts as text editor, spending seconds each time to understand where to go with ctrl+click, and its not only TS/JS, its same for Angular - also spinning CPU each time you hover something or ctrl+click…

@vsavkin just uses IDEA, jetbrains IDEs have no such problems, but they dont have proper NX extension - existing 3rd party one breaks after each update, nowdays for example custom generators not working…

There was hope that this exponential grow of VSCode will make it as powerfull as IDEA in few years, but majory of users using it to write Hello-world apps with React and filming Youtube videos - there is just no demand to fix this.

I think best option is to switch to become some Unity or Android developer to fix this problem 😁

The https://github.com/microsoft/TypeScript/issues/56268 issue got closed (“Working as Intended”). We need some official Nx docs/resource we can follow in order to solve this problem

unstall this issue @vsavkin @FrozenPandaz , can you please tell us, wo is responsible for dealing with this issue? 😉 This is a major issue that should be addressed, i think

We also cannot use refactoring methods like ‘renaming’ in VS Code. This slows down the development time massively. This issue needs more attention by the NX team!

We also have many issues with “Goto Definition” or “Find References”. Most of the time its very slow and intellisense if often not up-to-date . See also microsoft/vscode#4508 .

We switched to NX because of faster build times. We got it, but this problem negates all advantages of NX.

This still seems like a very pressing issue - if it’s not something that can/will be “fixed” by Nx itself, is it possible that a recommended approach to TS config could be published in the docs somewhere so that Nx users making use of VS Code (presumably most of them?) aren’t losing core basic Typescript functionality like Rename?

How are the Nx team working around this in their projects?

AFAICT this still hasn’t been fixed.

This is still a major issue for me. It is impossible to find consumers of let’s say a function that is part of a shared Nx library by using the Find all references feature of the TypeScript langage server used by VS code, which is by far the most used IDE in web development. Want to rename a symbol? Now all code that depends on it is broken because it wasn’t updated. And having to search by string matching is really inefficient and prone to error.

Has anyone found a solution yet?

Hi @johannesschobel ,

I tried what you proposed, it does not solve every issue I have.

• X Find all references does not work
• X Import suggestions does not work
• V Auto update import of moved files works

@FrozenPandaz Any updates on this?

Yes @amayer42 , it looks like the composite flag should be introduced for libs only. Also, after upgrading NX and Angular to 10, the workaround I described in the issue doesn’t work. Some changes were introduced to TS configs, so that I needed to extend my fix. Here’s what I came up with.

Workaround for NX 10

1. Add a root level tsconfig.json. This file is the “solution” tsconfig as per the following recommendation. It is not involved in the build process. It looks like tsserver requires a root level tsconfig.json to correctly handle multiple related TS-projects (see the related issue https://github.com/microsoft/vscode/issues/12463).

{
  "extends": "./tsconfig.base.json",
  "files": [],
  "include": [],
  "references": [
    { "path": "./apps/<app1-name>" },
    { "path": "./apps/<app2-name>" },
    { "path": "./libs/<lib1-name>" },
    { "path": "./libs/<lib2-name>" }
  ]
}

1. Add a root level tsconfig.base-lib.json, which will be the base configuration file for all the monorepo libraries. It will basically make our lib projects composite.

{
  "extends": "./tsconfig.base.json",
  "compilerOptions": {
    "composite": true,
    "declaration": true
  }
}

1. For every monorepo library modify the /libs/<lib-name>/tsconfig.json file. Inherit it from the root tsconfig.base-lib.json and remove files and include entries.

Before

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

After

{
  "extends": "../../tsconfig.base-lib.json",
  "references": [
    {
      "path": "./tsconfig.lib.json"
    },
    {
      "path": "./tsconfig.spec.json"
    }
  ]
}

1. Restart TS server or VS Code.

From now on, all the monorepo projects are automatically discoverable by TS server and you can find usages/refactor library’s interfaces in VS Code.

Works in the following environment

  nx : Not Found
  @nrwl/angular : 10.2.1
  @nrwl/cli : 10.2.1
  @nrwl/cypress : 10.2.1
  @nrwl/eslint-plugin-nx : Not Found
  @nrwl/express : Not Found
  @nrwl/jest : 10.2.1
  @nrwl/linter : 10.2.1
  @nrwl/nest : 10.2.1
  @nrwl/next : Not Found
  @nrwl/node : 10.2.1
  @nrwl/react : Not Found
  @nrwl/schematics : Not Found
  @nrwl/tao : 10.2.1
  @nrwl/web : Not Found
  @nrwl/workspace : 10.2.1
  typescript : 3.9.7

There is a possible gotcha hidden in your project tsconfig.json file that has not been mentioned here. If you have set baseUrl then VS code cannot find your module in libs (typescript error). This results in the problem described.

"compilerOptions": {
    "baseUrl": ".",
}

Remove it and it works again. If you do your internal imports without path navigation

import { thing } from 'components/thing';

then you will need to add it back in

import { thing } from '../components/thing'; 

Hope that helps someone!

which is already poor without nx

Seriously? The TS Dev Experience is one of the smoothest in my opinion…

This is still an issue 😕 and it really breaks the DX while refactoring code (i.e. I cannot just simply rename properties/methods etc. that might be shared used outside a lib, I have to rely on search & replace to be sure)

Maybe @vsavkin or @FrozenPandaz can join and provide feedback and maybe a hotfix for nrwl/nx. This issue may be a serious problem in the long run. You can also take a look at microsoft/vscode#4508 where i reported similar problems / issues with additional information

Dear @tomtaz ,

i think, a better solution is as follows:

1. leave your tsconfig.base.json as is
2. in every app / lib folder look for the tsconfig.json file and adapt as follows:

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

i.e., comment out the files array and add **/*.ts to the include. This will have the same effect, but follows the nrwl approach more accurately, i guess.

The microsoft/TypeScript#56268 issue got closed (“Working as Intended”). We need some official Nx docs/resource we can follow in order to solve this problem

2024-04-15 SOS

AN issue is opened here, and we’re getting help from the vscode folks on it. https://github.com/microsoft/TypeScript/issues/56268

@andriychuma Thanks for the details! I actually ended up using https://github.com/google/wireit with pnpm workspaces and that provides me with everything I need for now. I don’t think I really need the extra capabilities of nx at the moment. Wireit does a fantastic job of running my build tasks in parallel with caching and has very simple configuration.

FWIW I ended up needing a similar tsconfig setup, nx or not. I think that’s just how ts generally ends up needing to be configured to work in a monorepo layout.

@evelant, the issue is not fixed yet, but I don’t think it should be a pitfall on your Nx monorepo journey. Even being fixed, it’s quite likely you wouldn’t avoid additional manual adjustments. A multi-project TypeScript repository with project interdependencies should have a properly configured dependency tree for IntelliSense/TSServer to work properly in VS Code. When you add a new app or lib into your monorepo, Nx CLI doesn’t know its future relationships with other apps, that’s where manual intervention might be needed.

I took the latest Nx v15.2.1 and tried to identify the config adjustments needed for IntelliSense to work fine. There might be some edge cases that I didn’t test, but the following tweaks fix the issue.

I created a fresh new monorepo and added three projects:

• client, an Angular application
• server, a NestJs application
• shared, a library for sharing stuff between client and server

Here’s the initial structure of tsconfigs:

├── apps
│   ├── client
│   │   ├── tsconfig.app.json
│   │   ├── tsconfig.editor.json
│   │   ├── tsconfig.json
│   │   ├── tsconfig.spec.json
│   ├── server
│   │   ├── tsconfig.app.json
│   │   ├── tsconfig.json
│   │   ├── tsconfig.spec.json
├── libs
│   ├── shared
│   │   ├── tsconfig.json
│   │   ├── tsconfig.lib.json
│   │   ├── tsconfig.spec.json
├── tsconfig.base.json

Then I tweaked them a little bit and added a solution-like tsconfig in the root folder:

├── apps
│   ├── client
│   │   ├── tsconfig.app.json
              "compilerOptions": {
                "composite": false, // added
                "declaration": false // added
              },
│   │   ├── tsconfig.editor.json
│   │   ├── tsconfig.json
              "include": ["**/*.ts"], // modified
              // "references": [...], // removed whole section
              "compilerOptions": {
                "composite": true, // added
                "declaration": true // added
              },
│   │   ├── tsconfig.spec.json
│   ├── server
│   │   ├── tsconfig.app.json
              "compilerOptions": {
                "composite": false, // added
                "declaration": false // added
              },
│   │   ├── tsconfig.json
              "include": ["**/*.ts"], // modified
              // "references": [...], // removed whole section
              "compilerOptions": {
                "composite": true, // added
                "declaration": true // added
              },
│   │   ├── tsconfig.spec.json
├── libs
│   ├── shared
│   │   ├── tsconfig.json
              "include": ["**/*.ts"], // modified
              // "references": [...], // removed whole section
              "compilerOptions": {
                "composite": true, // added
                "declaration": true // added
              },
│   │   ├── tsconfig.lib.json
│   │   ├── tsconfig.spec.json
├── tsconfig.base.json
├── tsconfig.json (added the solution tsconfig file)
      {
        "references": [
          {
            "path": "apps/client/tsconfig.json"
          },
          {
            "path": "apps/server/tsconfig.json"
          }
        ]
      }

Now if you export an interface from the shared lib and use it in client and server, it will be properly discoverable by IntelliSense from any place.

@andriychuma is this still an issue? I just stumbled upon this issue and it’s making me question whether I should continue to work on integrating nx into my existing repo. If it’s going to break TS dev experience (which is already poor without nx) then I’ll have to rethink things.

Hello there,

Here is my fix that addresses everything and breaks nothing that I’m aware of. Ping me otherwise. I would be interested to know about the performance impact on build time for large repos with many apps/libs.

In tsconfig.base.json, add this:

{
  "includes": ["**/*.ts"]
}

Replace the tsconfig.json of every library by:

{
  "extends": "../../tsconfig.base.json"
}

Dear @andriychuma ,

thank you for your proposed solution in comment ( https://github.com/nrwl/nx/issues/3106#issuecomment-703154400 ), however, this does not work for me (see issue with updating file imports).

Do you have, by chance, the same issue? Does your solution work for the latest NX?

All the best