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

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

Open
sgoossens opened this issue Jul 22, 2021 · 6 comments
Labels
Domain: Auto-import Needs Investigation This issue needs a team member to investigate its status.
Milestone

Comments

@sgoossens
Copy link

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.

@vscodebot
Copy link

vscodebot bot commented Jul 22, 2021

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

@mjbvz
Copy link
Contributor

mjbvz commented Jul 22, 2021

Please share a minimal example project that demonstrates this issue

@sgoossens
Copy link
Author

@mjbvz mjbvz transferred this issue from microsoft/vscode Aug 2, 2021
@mjbvz mjbvz removed their assignment Aug 2, 2021
@mjbvz
Copy link
Contributor

mjbvz commented Aug 2, 2021

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

@sgoossens
Copy link
Author

sgoossens commented Aug 3, 2021

@mjbvz After installing the extension, Typescript was able to auto import 3rd party dependencies, however it would not install the dependencies coming from within the project. I pushed changes to the repo to reflect all the imports that could be done automatically with the extension above

@RyanCavanaugh RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label Aug 5, 2021
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Aug 5, 2021
@sam-mfb
Copy link

sam-mfb commented Aug 13, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Domain: Auto-import Needs Investigation This issue needs a team member to investigate its status.
Projects
None yet
Development

No branches or pull requests

4 participants