TypeScript: Automatic imports don't work for packages that provide their own types
- VSCode Version: 1.41.0
- OS Version: Fedora 30
Steps to Reproduce:
- Add a module dependency which includes it’s own types
- Start writing out a named export of the added module
- No suggestion will be given
Suggestions won’t show until you’ve actually imported the dependency.
This is different from how @types modules work, which will show in suggestions without any prior use.
I’ve created an example project
yarn install- open
src/main.ts - type
useand you will get suggestions for ReactuseCallback, etc. - type
watchand you will get no suggestion for Kappiwatch
Does this issue occur when all extensions are disabled?: Yes
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 6
- Comments: 22 (8 by maintainers)
@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
@types.Regarding that explanation, you don’t have to look for all
.d.tsfiles innode_modules, you only have to look in the module folders of direct dependencies defined in your projectspackage.json. (Maybe @RyanCavanaugh can comment)A further optimization (with some drawbacks) would be to only include the
.d.tsdefined in thetypesfield ofpackage.jsonfor direct dependencies. This would mean though that nested types such aspackage-name/foocould not be included since thetypesfield can only link to one file. Unless maybe one main.d.tsimported them, but I haven’t tested that so not sure it works.@andrewbranch It was reproducible in 3.8.3 from my previous ticket: https://github.com/microsoft/TypeScript/issues/37187#issuecomment-594103856.
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.
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.
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
--listFilesfiltered forrxjs- looks like it’s picking it up, but not showing as suggestions in vscode:EXPAND ME
So after some trying with a minimal example, I found my issue to be related to the yield keyword. See https://github.com/microsoft/TypeScript/issues/36933
Use ⌘. (macOS) or Ctrl+. (Windows) to trigger code fixes 😄
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.
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
tsc -p your-tsconfig.json --listFilesIf 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
typeRootswas updated to acceptnode_moduleswithout errors, instead of error when encountering a package without types, it would need to skip it.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
@typesdependencies.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
typesin tsonfig, which can be tedious when starting a project and adding dependencies.For performance issue: Why not allowed users to decide with use of for example tsconfig ???
Perhaps I’m misunderstanding something, but doesn’t every
@typespackage also include a performance hit? Say you have 8@typespackages what would really be the performance difference to 8 first party typed packages?Yes that’s understood, but imagine this scenario: You just added a dependency and it’s 3rd party types. Of course you don’t have that imported anywhere in your project yet, but auto-import helps you out so you can use that library right away.
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.
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.
@SantoJambit there is kind of already a tsconfig option which is to explicitly define
compilerOptions.types, but that means when you add a dependency you need to also add it to thetypesarray.There’s also
typeRootswhich you might expect to work if you used"typeRoots": ["node_modules/@types", "node_modules"], but if any package in the definedtypeRootsfolders don’t include types, then typescript errors.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: https://github.com/microsoft/TypeScript/issues/30033#issuecomment-467991747