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 multi-root workspace autoImportFileExcludePatterns not being excluded from autocomplete [monorepo] #2479

Open
datstarkey opened this issue Aug 29, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@datstarkey
Copy link

datstarkey commented Aug 29, 2024

Describe the bug

When using a mono-repo its quite common to share some components and export them without building as they'll never be released as a library. using the exports and pointing svelte and types to the index.ts works, and provider correct intellisense

when using pnpm workspace for this, the imports all work fine however the quick-fixes/code completion suggests the relative path alongside of the import which is incorrect, as sub paths is not allowed and should only be imported from the index.ts.

image
This also seems to be a random order, as sometimes the first completion is the relative path instead of the shortest one, I've played around with all the importModuleSpecifiers and it doesn't seem to affect the order of them. This can be insanely annoying if you have multiple components with the same name like InputText,InputNumber,InputDate, resulting having to go down alot of different imports before the one you want.

Inside of the vscode settings at the root of the monorepo you can add the autoImportFileExcludePatterns to get around this.
image

Resulting in the auto-complete only giving the desired result.
image

This is great, however if you use a vscode multi-root workspace, this stops working. I've tried adding the settings to the .code-worspace and it works as Intended inside typescript files but not inside svelte files. so it looks like the typescript-plugin isn't detecting the code-workspace settings?

Reproduction

https://github.com/datstarkey/svelte-workspace-import-exclude/tree/master

  1. clone the repo and pnpm i
  2. open the root directory first not the workspace.
  3. go to packages/src/lib/working.ts and run the quickfix on stuff, notice only the correct import is available.
  4. go to packages/src/lib/notWorking.svelte and run the quickfix on stuff, notice only the correct import is available.
  5. open the project from the monorepo.code-workspace inside the root.
  6. repeat steps 3 & 4, notice how the typscript file works, but the svelte file still gives the wrong import.

Expected behaviour

The typescript.preferences.autoImportFileExcludePatterns vscode setting should produce the same behaviour in workspace or folder/root level for svelte files.

System Info

  • OS: [Windows]
  • IDE: [VSCode]

Which package is the issue about?

Svelte for VS Code extension

Additional Information, eg. Screenshots

The main problem, when completion tries to fill in it always has the longest at the top
image

@datstarkey datstarkey added the bug Something isn't working label Aug 29, 2024
@jasonlyu123
Copy link
Member

jasonlyu123 commented Aug 29, 2024

The problem isn't config not detected but because we limit the pattern to the workspace root. ex: shared/src/components => c:/path/to/repo/packages/app/**/shared/src/components. This was done because the original implementation in the VSCode we migrated from doesn't work in Windows and we are not sure if it was intended to ignore c:/**/shared/src/component or c:/path/to/repo/packages/app/**/shared/src/components. But this is fixed in VSCode 1.88 and TypeScript 5.4. We'll have to change how we normalize the setting to match the new behaviour.

About "the main problem", the language server prioritizes .svelte import. It Might make sense not to prioritize it when we see a barrel import in the completion list as well.

@datstarkey
Copy link
Author

Ahh okay, that makes sense thanks :)

In terms of the import prioritization, should it only prioritize if the path is within the root of the project, and deprioritize(or even ignore?) if its not. When building a library project within the same monorepo, you'd want it to use relative paths inside the lib to avoid accidental circular dependencies if your doing multiple barrels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants