Repository navigation
Automatic imports don't work for packages that provide their own types #36042
Description
- 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
Activity
SantoJambit commentedon Jan 3, 2020
Same issue here. Ubuntu 18.04
Suggestions start appearing once you manually imported at least one type from the module in your file.
SantoJambit commentedon Jan 7, 2020
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 commentedon Jan 15, 2020
Very surprised we didn't find out about this sooner.
[-]Suggestions don't work for modules with bundled types[/-][+]Suggestions don't work for packages that provide their own types[/+][-]Suggestions don't work for packages that provide their own types[/-][+]Automatic imports don't work for packages that provide their own types[/+]andrewbranch commentedon Jan 21, 2020
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)
robbiespeed commentedon Jan 22, 2020
Andrew Branch (@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 Ryan Cavanaugh (@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.10 remaining items
senpl commentedon Jan 23, 2020
For performance issue: Why not allowed users to decide with use of for example tsconfig ???
robbiespeed commentedon Jan 23, 2020
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
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.SantoJambit commentedon Jan 23, 2020
Thanks for the detailed explanation Andrew Branch (@andrewbranch). I would still go with Robbie Speed (@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.
backbone87 commentedon Feb 16, 2020
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"] }DanielRosenwasser commentedon Feb 18, 2020
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 --listFilesSantoJambit commentedon Feb 20, 2020
Edit: The bug I experienced was about using the yield keyword in front of they name to autoimport. See #36933
andrewbranch commentedon Feb 20, 2020
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.
andrewbranch commentedon Feb 20, 2020
Use ⌘. (macOS) or Ctrl+. (Windows) to trigger code fixes 😄
SantoJambit commentedon Feb 21, 2020
So after some trying with a minimal example, I found my issue to be related to the yield keyword. See #36933
admosity commentedon Mar 4, 2020
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:
With quickfix:
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
andrewbranch commentedon Mar 5, 2020
Adam (@admosity) can you try with TypeScript 3.8.3?
admosity commentedon Mar 14, 2020
Andrew Branch (@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.