"Organize Imports" should adjust specifiers based on preferences

[leqwasd]

🔍 Search Terms

"sort imports", "organize imports"

✅ Viability Checklist

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

⭐ Suggestion

I have a feature request for the language server / it's commands.

So I have a large project, and I have not changed tsconfig.json since the beginning of the time. Now I "discovered" what baseUrl does, what paths does, and that there is an option in vscode - ```

"typescript.preferences.importModuleSpecifier": "non-relative", // | "project-relative" | "relative" | "shortest"`.

So I have a file, deep inside the source - which imports from a file, close to the root. Before I added 'baseUrl' - it did

import { bar } from "../../../../../foo/bar";`

After adding "baseUrl": "./src/" in tsconfig - this could be written as

import { bar } from "foo/bar";`

bar();

If I delete the import, and go to the bar() to fix the import issue - it provides me quick fix -

• Add import from "foo/bar" if I have specified "typescript.preferences.importModuleSpecifier": "shortest" in settings., or
• Add import from "../../../../../foo/bar" if I have specified "typescript.preferences.importModuleSpecifier": "relative" in settings.

I really don't like those endless "../../../../../" so I would like to fix them. The only "tool" I have for now - is just to delete the import, and resolve those imports manually - so it gives me the best import paths given my settings and my tsconfig's "baseUrl" or "paths".

This is tedious. And it doesn't work where I have used import * as foo from [..].

In VSCode - there is a command Organize imports (I think this comes not from TypeScript?) (In my optionion - wasted effort. since it doesn't organize them, it just sorts them, but this is besides the point (it does not come from TypeScript))

But TypeScript does come with a command "Typescript: Sort imports"!

What I would want - after executing the command, it would not only sort the imports, but also - change the paths for those imports matching my preferences of settings.json "typescript.preferences.importModuleSpecifier" + tsconfig.json "baseUrl" and "paths".

Or it could be a new command - Typescript: Organize imports? (maybe not..)

📃 Motivating Example

This feature would help automatically shorten imports / make the satisfy project setting for a file.

💻 Use Cases

1. What do you want to use this for? To automatically organize imports
2. What shortcomings exist with current approaches? You have to manually go over each import and edit them one by one
3. What workarounds are you using in the meantime? Deleting the import and resolving them using quick fix.

[DanielRosenwasser]

In my optionion - wasted effort. since it doesn't organize them, it just sorts them, but this is besides the point

For what it's worth, organize imports is a command that combines two commands:

• Sort imports
• Remove unused imports

(see more here)

Neither of those individual commands should (in my opinion) rewrite paths. But I could imagine "organize imports" might.

[leqwasd]

Well, I created a fork, where I created a code fix action for this - when checking file for suggestions, it also now inspects imports. it calls basically the same function that is executed, when Add Import action is executed, gets all available modueSpecifiers for the import. If returned moduleSpecifiers are different, adds suggestion + later a codeFix action that can change the import path.

There needs to be a review made, because I had to add new parameters to the computeSuggestionDiagnostics function, which is called from different places, I am not sure, I filled those parameters correctly.

I didn't create a PR because I couldn't check this [ ] There is an associated issue in the Backlog milestone (required)