Preventing `importScripts(…)` (ambient declaration) from being suggested ahead of import statements.

[lgarron]

🔍 Search Terms

importScripts import imports ESM

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

When I type imp… into a JS project with the DOM API in VS Code, the first suggestion is always the ambient importScripts(…) function.

Note that this happens in any JS/TS file, regardless of whether I'm writing web worker code. I have well over a decade of experience with web workers and I understand the historical importance of this function, but as of several years ago this suggestion is never appropriate for me.

I would like a way to either:

• Ensure the import statement suggestion is always place ahead of importScripts(…).
• Prevent importScripts from ever showing up as a suggestion.

📃 Motivating Example

This allows developers to get the suggestion for the vastly more often-used import — a simple ergonomic win for what might be the most widely used syntax completion in JS/TS file.

It also recognizes that importScripts has gone the way of the past. Even when writing web worker code, it's been possible to use cross-browser module workers since 2023 with vastly better ergonomics. So importScripts is essentially on the way to becoming a legacy API.

💻 Use Cases

1. What do you want to use this for?

Any time I import anything in any JS/TS file.

2. What shortcomings exist with current approaches?

Change VS Code settings to "editor.suggestSelection": "recentlyUsed". This can kind of work, but it breaks repeatability (and therefore muscle memory) for all other import completions.

VS Code also supports javascript.preferences.autoImportSpecifierExcludeRegexes and typescript.preferences.autoImportSpecifierExcludeRegexes. These are a good precedent for being able to prevent certain suggestions, but I don't think they can help here.

3. What workarounds are you using in the meantime?

I've investigated a bunch, and I'm not aware of any other workarounds.

[guillaumebrunerie]

Seems to me like something is wrong with your TS config. For me importScript is only suggested in web worker files, not in regular JS/TS files (which makes senses, as this global function is only available in web workers).
Also don’t you use auto imports? I rarely ever write import by hand, I simply use the function I need and autocomplete it, which automatically adds the correct import at the beginning of the file.

[lgarron]

Seems to me like something is wrong with your TS config. For me importScript is only suggested in web worker files, not in regular JS/TS files (which makes senses, as this global function is only available in web workers).

Hmm, how would TypeScript know if we're in a web worker file?

In any case, this happens even if I run npm install --save typescript in an empty folder and then start writing code in an empty file.

Also don’t you use auto imports? I rarely ever write import by hand, I simply use the function I need and autocomplete it, which automatically adds the correct import at the beginning of the file.

All the time. Love to use them. But:

• The lack of Import support for snippets vscode#244133 means I constantly have to add missing imports to snippets.
  • I can sometimes go over each of the missing imports and use ⌘. to select a suggestion. But that also often doesn't work, for the reasons below.
  • I've recently tried to start using "Add all missing imports", but 1) that also often doesn't work for the reasons below, and 2) it can result in the wrong import being added (even when set to only add imports that have a single option, because that only option might be a false positive). So I sometimes have to fix that up.
• Some imports are simply not suggested. Often I can't import from a package until the import statement is already in the file.
• Newly created files don't belong to typescript project on MacOS #45721 keeps coming back in various forms. Newly added files are often not indexed.
• After updating node_modules, dependencies are not always indexed proactively.
• Sometimes the imports can't be completed, e.g. when you have to use the default import for a legacy library, or if you need a side effect import. (In the latter case you have to remove {} from but it's still ergonomic to start from the full import statement).
• I have a bunch of imports blocked, mostly to to prevent imports suggestions that I rarely/never want (so that I can more easily get the ones I do want). I occasionally need to add import statements for these manually.

[guillaumebrunerie]

Hmm, how would TypeScript know if we're in a web worker file?

I had to set this up recently for service workers and followed https://joshuatz.com/posts/2021/strongly-typed-service-workers/
Basically there are a few different ways, but the simplest one is probably to make sure your web workers are in a separate subfolder and then you can have a tsconfig.json with lib WebWorker in that subfolder to tell TypeScript that only files in there are web workers.

In any case, this happens even if I run npm install --save typescript in an empty folder and then start writing code in an empty file.

It might very well be that the default lib contains WebWorker.

[lgarron]

It might very well be that the default lib contains WebWorker.

It does. lib.d.ts contains:

/// <reference no-default-lib="true"/>

/// <reference lib="es5" />
/// <reference lib="dom" />
/// <reference lib="webworker.importscripts" />
/// <reference lib="scripthost" />

[RyanCavanaugh]

I see importScripts below import as requested. You might have some other configuration set that's causing this?

[lgarron]

I see importScripts below import as requested. You might have some other configuration set that's causing this?

Wild, looks like this is no longer deterministic on my own device.

I was still able to observe the behaviour in a blank repo, then I tried clearly and restoring my VS Code settings.json and now I no longer do. (This is something that I do once in while for debugging — I'm not sure why it helped this time.)

(Now the implements keyword is first for me, which is not much better.)

[lgarron]

Okay, I'm not sure what's going on. I'm gonna close this for now until have a consistent repro again.

Thanks for the poke, @RyanCavanaugh!