VSCode version 1.58.2 Not able to add new imports in Typescript rush monorepos

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.58.2
• OS Version: macOS Big Sur 11.4
• Extension ids: [coenraads.bracket-pair-colorizer, wmaurer.change-case, streetsidesoftware.code-spell-checker, dbaeumer.vscode-eslint, file-icons.file-icons, eamodio.gitlens, esbenp.prettier-vscode, netcorext.uuid-generator, vscodevim.vim]

Steps to Reproduce:

1. Create an interface Foo in a new location
2. Create a class that depends on the Foo interface and try to auto import the definition through the VSCode auto import feature (highlight the interface and use command + . to open the suggested actions)
3. The only option it will give the user if nothing has been imported from this location before is to extract to a type alias
4. If something had been imported from the same location however, it can add the import to the existing list of imports

What should happen:

VSCode should suggest creating a new import statement for that interface at the top of the class file

What actually happens: using command + . yields only the option to Extract to type alias.

[sam-mfb]

This issues seems to crop up quite a bit in the rush monorepo context. I spent a couple days investigating it with the help of some of the rush folks, and I think I have a summary of what’s going on, which I’m posting here in the hope it helps others.

TLDR: the issue is fixed in the current nightlies of TS and VSCode, and there is a fairly simple workaround for stable releases.

There is a problem with the interaction between TS 4.3.5 (and presumably earlier versions) and PNPM workspaces. You can see it very easily in this repository which is a totally vanilla pnpm library with workspaces turned on and TS version 4.3.5 as a dep. Just do a pnpm install on the repo and then look at the test file in utils/foo/src/index.ts in VSCode. You’ll see that autoimport/intellisense do not work on the call to useEffect(). You can see the problem in VSCode and in vim running coc.nvim.

You can double check that autoimport does work in a vanilla npm repository by looking at the same file in this plain npm repo for the same project.

(The same problem also occurs in a rush repo–e.g., this one–but that’s really just because rush uses pnpm in its default configuration.)

The problem goes away if you upgrade typescript to typescript@next AND use the current nightly build of VSCode. You need to do both. If you are using the current version of coc.nvim you just need to upgrade TS.

So, the issue appears to be an interaction between TS, pnpm, and VSCode which is fixed in the nightly builds. I’m not sure where.

If you don’t want to, or can’t, live on the bleeding edge, there’s a fairly easy workaround–which you can see at work in the commented out line in the utils/foo/src/index.ts file in the test repo. Basically, if you hint to the TS Server where to find your symlinked node_modules file once, it will then use it throughout your project. The simplest way to do that is in three steps:

1. Select a folder in a project that will not get built/webpacked/whatever, but that will get seen by typescript. We use a __mocks__ folder.
2. Create a file, e.g., auto-import-hint.ts, that contains a line that imports a package from your node_modules folder using a relative path, e.g. import from "../node_modules/typescript" (depending on your config the path might need to be slightly different, e.g., in one of ours we had to use "src/../node_modules/typescript")
3. There is no step three

That file is enough to hint to TS/VSCode where all your symlinked packages are. We are using this in a couple projects and haven’t experienced any problems with this fix so far.

Hope this helps.

[mjbvz]

Thanks @sgoossens

Can you also try upgrading the test work workspace to use typescript@next by installing this extension to make sure this has not already been fixed