Automatic imports don't work for packages that provide their own types #36042
Comments
|
Same issue here. Ubuntu 18.04 Suggestions start appearing once you manually imported at least one type from the module in your file. |
|
I've tried downgrading vscode to 1.37 and typescript to 3.3.4000. The issue remains. I even tried disabling all extensions and resetting all settings to their defaults without success. I'm pretty sure, that it worked correctly with the above versions, so I'm not sure where this issue is coming from. |
DanielRosenwasser
added
Bug
|
Very surprised we didn't find out about this sooner. |
DanielRosenwasser
changed the title
DanielRosenwasser
changed the title
|
This is working as intended and/or duplicate of #29629, #30033, and #30474.
Not just in the same file, but anywhere in the project. See Ryan’s explanation here: #30033 (comment) |
|
@andrewbranch If this is working as intended then that's pretty disappointing, because it means libraries with first party type definitions are less user friendly then those who have third party definitions in Regarding that explanation, you don't have to look for all A further optimization (with some drawbacks) would be to only include the |
|
I agree with @robbiespeed. Why punish real TypeScript projects? |
|
@SantoJambit there is kind of already a tsconfig option which is to explicitly define There's also |
This is something that’s been on my mind since #32517. Prior to that PR, we didn’t have an in-memory cache of package.json dependencies. But, it’s still going to be a performance hit on completions no matter what—you’re asking for global completions to do an arbitrary additional amount of work and/or hold an arbitrary additional amount of program data in memory. This request has come up a couple times in the past, and it’s something I’m interested in experimenting with, but based on the relatively low traction on these issues, I’m still skeptical that the performance tradeoff will be worth it.
I want to reiterate that once you have a single import from a package anywhere in your project, auto-imports from that package work everywhere in your project. |
andrewbranch
added
In Discussion
Perhaps I'm misunderstanding something, but doesn't every
Yes that's understood, but imagine this scenario: Now you add a dependency with 1st party types, you do the exact same thing as before and attempt to use it right away, but this time you can't. Even though this dependency was made with TypeScript, it has a worse user experience. |
To understand the difference, you have to know a little bit about how type resolution works in the compiler. The difference is that, for better or for worse, all When you make a change to a source file in your editor, TypeScript sees the change and reevaluates the state of your program. It re-parses what it needs to, analyzes that change to determine if it could change which files are included in the whole program compilation, updates that list of files if necessary, and creates a new type checker. All this happens just to make sure your editor is ready to tell you accurate types and errors, should you ask for them. Then, features like auto-import ask the new checker for a list of external modules and their respective exports. At this point, getting that list is basically free because the work to go resolve them, parse them, and bind them was already done because of the default rules of type resolution. In other words, auto-imports work for So knowing this, if you want auto-imports to work for non- |
DanielRosenwasser
added
the
Awaiting More Feedback
|
For performance issue: Why not allowed users to decide with use of for example tsconfig ??? |
If there was an option in tsconfig then it wouldn't be a breaking change. You wouldn't even need to make a new option if In this case I don't think there's any performance concern, because you're most likely to be importing those modules at some point anyway. And there's no more of a concern of new globals then there is with
The idea of a separate process for auto-imports would help solve some other issues. It could allow no types would be included by default, you would need import them. This would help a bunch in instances where globals conflict in sub projects like with DOM and WebWorkers, or globals from testing suites get added to your program. The only way around that kind of issue right now is to explicitly define |
|
Thanks for the detailed explanation @andrewbranch. I would still go with @robbiespeed here and say that if I have them in my (first class) package.json, then I will obviously import them at some point and thus nullify the performance argument. |
that does not work for me. only once i imported something from this external module in the exact same file further suggestions from this module are available. TS 3.7.5 tsconfig.json{
"compilerOptions": {
"target": "es2019",
"module": "commonjs",
"strict": true,
"importHelpers": true,
"moduleResolution": "node",
"experimentalDecorators": true,
"emitDecoratorMetadata": true,
"esModuleInterop": true,
"forceConsistentCasingInFileNames": true,
"resolveJsonModule": true,
"sourceMap": true,
"incremental": true,
"baseUrl": ".",
"outDir": "dist",
"types": ["node"],
"typeRoots": ["src/types", "node_modules/@types"],
"paths": {
"@/*": ["src/*"],
"@@/*": ["*"]
},
"lib": ["esnext"],
"plugins": [{ "transform": "ts-transform-paths" }]
},
"include": ["src/**/*.ts"],
"exclude": ["node_modules"]
} |
|
If you have an example that doesn't exhibit the root cause here, please file a separate issue with a minimal repro so we can easily diagnose it. As a quick check though, make sure the tsconfig contains your files via |
|
Edit: The bug I experienced was about using the yield keyword in front of they name to autoimport. See #36933 |
|
It is true that codefixes (lightbulb) for auto imports cover more cases than completions (show up as you type, or triggered manually with ctrl/cmd+space). But, looking at the type definitions for redux-saga, I don’t see why this would be one of those cases. I would definitely call that behavior undesirable, if not an outright bug. |
Use ⌘. (macOS) or Ctrl+. (Windows) to trigger code fixes 😄 |
|
So after some trying with a minimal example, I found my issue to be related to the yield keyword. See #36933 |
I seem to be having a problem even with the base functionality here.. My other ticket #37187 was transferred from VSCode so maybe it's an actual vscode problem. VScode:
Other file in same project with the same import: Atom:
Output from EXPAND ME
|
|
@admosity can you try with TypeScript 3.8.3? |
|
@andrewbranch It was reproducible in 3.8.3 from my previous ticket: #37187 (comment). We're using a meta-package that bundles a number of other dependencies for the purpose of managing several applications. Moving all the dependencies in that meta-package back into the project allows those dependencies to be picked up by intellisense (in VSCode). It seems that TypeScript itself shows that it is picking up those dependencies but VSCode itself may be stripping anything that is not present in the project's package.json. I am guessing Atom is unaffected by this because it is leveraging the full output for TypeScript's listing. I will see if I can create a simple reproduction of my specific case. |
Steps to Reproduce:
Suggestions won't show until you've actually imported the dependency.
This is different from how
@typesmodules work, which will show in suggestions without any prior use.I've created an example project
yarn installsrc/main.tsuseand you will get suggestions for ReactuseCallback, etc.watchand you will get no suggestion for KappiwatchDoes this issue occur when all extensions are disabled?: Yes
The text was updated successfully, but these errors were encountered: