No auto imports in new JavaScript file

[DarceyLloyd]

TS Template added by @mjbvz

TypeScript Version: 3.8.0-dev.20200201

Search Terms

• auto imports
• auto import

---

• VSCode Version: 1.41.1
• OS Version: Win 10 x64 Latest

Steps to Reproduce:

1. create folder
2. npm init
3. npm i aftc-modules
4. open vscode
5. create index.js
6. type in AttachDebug
7. press ctrl and space
8. no suggestions for import

I've also posted on, to see if it's something other than VSCode:
https://stackoverflow.com/questions/60063424/vscode-autoimport-setup-configuration-enhancement

[andrewbranch]

There are a lot of overlapping reasons why this is happening:

• Ctrl+space is the keyboard shortcut for completions. Completions do offer auto-imports, but prior to Full support for CommonJS auto-imports in JS #37027, they would not work in a JS file under default project settings until there was some trace of ES module syntax in the file. This is now fixed. But, the issue still occurs because...

• Code fixes (Ctrl+.) have always worked better in JS files, but require JS file type checking to be enabled to work. But even if it had been enabled, the issue would still occur because...

• The library aftc-modules does not have type definitions on DefinitelyTyped. If it did, this issue would not have happened (as of Full support for CommonJS auto-imports in JS #37027 being merged). (It does not ship its own types either, but because it’s a top-level dependency, the language service will analyze the JS for exports.) This part of the issue is tracked by Automatic imports don't work for packages that provide their own types #36042. The known and accepted status of that issue, while suboptimal, is that once you write an import from a package like this anywhere in your project, auto-imports will work. But, even if @DarceyLloyd had written one import manually somewhere else in the project, this issue could still occur because...

• In VS Code, projects (TS or JS) that lack a tsconfig.json or jsconfig.json file only include the files that you have currently open in your editor.

  This means that you could create a new file, say test.js, and write in it import 'aftc-modules'. If you then switch tabs to index.js and type AttachDebug, the auto-import will work. But if you then close the tab for test.js, the auto-import will stop working, because under the hood TS Server has updated your program to include only the files you have open, the recursive dependencies/references of those files, and node_modules/@types/*. With test.js orphaned, aftc-modules is no longer in the program. Demo:

  

  I brought this up in our team chat, and @minestarks pointed out that Visual Studio uses a file-system-based approach to inferring what files belong to projects, which would solve this part of the issue, and I think provide a much better default experience for JS users. It wasn’t clear to me how much work it would be, and what the downsides might be, if we switched VS Code to that approach. @minestarks @sheetalkamat what are your thoughts? I searched through existing issues, but couldn’t find if this had been discussed in the past.

[DarceyLloyd]

Maybe support a lookup file on both JS and TS repositories? So that VSCode can just scan an installed repo for say definitions.js or definitions.ts which would be a function/class list which would point to a file where that function/class resides for loading on demand both the comment if available and the function/class name & params it takes if not? This would become a file that sits at repo root with package.json and npm.ignore etc

My aftc-modules package is just JS at the moment no TS version available (yet) but I'm not sure how to remedy this to work for VSCode other than to manually still get the include working.

RE: VSCode remembering the include when open in another file.
Once any export function from aftc-modules has been included all export functions become available in intellisense.

[andrewbranch]

@DarceyLloyd you can add a tsconfig.json or jsconfig.json for that purpose. Most JS users wouldn’t know to do that, though, so I’m using this issue to discuss the default, bare-bones JS experience.