-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Auto imports from referenced project not working until already imported once in project #39778
Comments
For me it's not a problem even for a session with screen sharing, if anything |
Can you share the project that causes this? |
Yup! |
@mjbvz here you go https://github.com/EKashpersky/mentare-102740-0 Each project has Works fine for 102740-1. |
Looks like Moving upstream to get the TypeScript team's feedback on this behavior |
Confirm this issue. My composite projects referenced to each other don't auto import names from other connected projects |
Confirm. Autocomplete not working via references in tsconfig.json demo: https://github.com/zerkalica/ts-references-autoimport-bug/tree/autoimport-no-ref Currently autocomplete works only with includes (cpu eating on big projects) and via "types" in package.json. Autocomplete doesn't works with direct imports (without types in package.json) |
Project reference imports like using |
Any update on this? How can Microsoft's IDE (written in TypeScript!) not properly support Microsoft's TypeScript 🤯 |
This might seem like a stupid suggestion, and it's probably super complex behind the scenes, but if it works by using the |
TypeScript doesn’t resolve types from “normal” node_modules dependencies without the |
any update here? my team would really like this issue fixed. |
The update was that it’s pretty hard to fix and almost nobody was interested enough to try my experimental branch for the 3 weeks that it was open. As far as I know the only issue here is that project references for Project B aren’t automatically made available for auto-import in Project A before there is an existing import that brings types from B into A. This is actually how all node_modules auto imports worked for many years before there was sufficient demand for us to write a (pretty complicated) feature to proactively pull in any package.json dependencies. Today, that feature also works for project references that are linked through node_modules in a workspaces-style monorepo, as long as the packages declare their dependencies on each other in their respective package.json files. So the feature I attempted at #47690 really only covers a narrow set of circumstances, and it turned out to totally ruin existing auto-imports caching infrastructure, so the current status is it’s definitely not worthwhile. I suspect many of the upvotes on this issue actually come from people who are experiencing some other bug or misconfiguration, not people whose issue would be solved by #47690. If you’d like to put together a small repro of your issue, I can take a look and see what the actual problem is. |
Sure, here's a repo that has the issue. This is based on a simplification of our own yarn monorepo. We've got a This example repo doesn't include any of this extra stuff because it suffices to show the issue, but for context, in our real repo Our biggest issue is the one mentioned in the comment above - VSCode auto-import suggests relative paths to the original
What I mean by that last point is, if I try it with the "Import Module Specifier" preference set to "shortest", it works (although with a relative path, which is still undesirable): But if I set "Import Module Specifier" to "non-relative", it curiously gives me: Which is simply broken - an immediate compilation error. It's totally possible - and would be great if! - this is just a configuration issue on our part and there's a different/better way to do it. Thanks for your help! |
Opened a new issue because that does sound different. Will take a look next week; thanks for the detailed info! |
Any news on this? Monorepos with @nrwl/nx are nightmare to use without suggestions. |
Nothing has changed since the last update |
I found autoimports working quite reliably if top level tsconfig includes all files. It will be unused by any particular file or project having own local configuration, but magically enables autocomplete. Also almost the opposite advice - do not reference workspace packages from a top-level config. Even for small projects it might take too much time to start language server, so you'll be left with no support as-you-type. |
@theKashey what do you mean by root level tsconfig including all files? |
The only way I got this working is to include the referenced projects' source code in |
Just realized if we include the referenced projects in Here is a sample to reproduce the issue. |
For those who want to fix the auto import in composite projects, I have a partial solution for you. I think as this already works out of the box with the current implementation, the TypeScript team might be able to actually leverage this, and fix the issue internally so we don't have to configure all the referenced projects to built files to make types available only for auto-import. Here is how it all works, you will have to add the built version of the referenced projects where the declaration files are generated in the A minimal base configs (that will be extended by the composite projects) look like this: {
"extends": "@tsconfig/strictest/tsconfig.json",
"compilerOptions": {
// required configs
"baseUrl": ".",
"rootDir": ".",
"outDir": "./built/local",
"composite": true,
"declaration": true,
"declarationMap": true,
"sourceMap": true,
// configure these based on your needs
"module": "esnext",
"target": "es2016",
"moduleResolution": "node",
"resolveJsonModule": true,
"jsx": "react-jsx",
"checkJs": false
}
} And a project that has references can include the built of {
"extends": "../../tsconfig-base",
"compilerOptions": {
"typeRoots": [
"../../node_modules/@types",
"../../built/local/app/shared",
],
},
"include": [
"**/*",
"**/*.json",
],
"references": [
{"path": "../shared"},
],
} And the shared project configs that was referenced above: {
"files": [],
"include": [],
"references": [
{"path": "./main"},
{"path": "./shared"},
],
} And then you'll have to build the whole project for the declarations to be available for auto-import to work by running This works only partially, and for some reasons the root exported declarations are not available in the auto import. In our example This should allow the incremental build, and the auto imports in vscode to work properly. |
FYI I got auto importing in a monorepo working by:
|
TS Template added by @mjbvz
TypeScript Version: 4.0.0-dev.20200727
Search Terms
Steps to Reproduce:
I have an Angular project, and just 1 of the files don't have a proper suggestion support in it.
Same happens when I create a file via plus sign from the side bar.
VSCode doesn't suggest "obvious(necessary)" things, quite the contrary happens:
it suggests everything else what's available, but not what I need and not what really exists in the project.
Also, when I try to import environment object with 'src/environments/environment',
it doesn't seem to know about src folder(project_name/src).
Although it already works this way for all the other files in the project.
Cache cleaning && insiders build didn't help out, no errors in debug console and I couldn't find any useful tsserver logs.
Although I can send if necessary.
Having 3.9.7 TS
Does this issue occur when all extensions are disabled?: Yes
The text was updated successfully, but these errors were encountered: