`tsserver` feature: `importModuleSpecifierPreference: "non-relative"` but allow siblings

Suggestion

🔍 Search Terms

importModuleSpecifierPreference
allow sibling

✅ Viability Checklist

My suggestion meets these guidelines:

• 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 feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Let auto-imports mirror:
https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-relative-parent-imports.md
or the old:
https://github.com/microsoft/tslint-microsoft-contrib/issues/778

New option, could be named anything, "non-relative-allow-sibling", "no-parent", "relative-iff-sibling", etc

📃 Motivating Example

re: "why this feature improves the language", this is not a language feature, but an IDE feature which happens to be handled by TypeScript repo:

https://github.com/microsoft/TypeScript/blob/3b45f4db12bbae97d10f62ec0e2d94858252c5ab/src/server/protocol.ts#L3487

Motivating example: When you auto-import, you want to import as ./foo if in same directory, otherwise something like @/utils/foo. shortest doesn't necessarily work since ../foo could be shorter than e.g. @/modules/feature/foo

💻 Use Cases

Currently using importModuleSpecifierPreference: "non-relative" as-is.

Start with the importModuleSpecifierPreference definition in src/server/protocol.ts at the linked location, then trace how tsserver chooses auto-import specifiers. Define how sibling files should use ./foo while other imports remain non-relative, and identify the relevant auto-import tests before implementing and validating the new option.