Background
#22158 tracks referencing types from a given module using JSDoc-style namepaths. Given that the syntax is somewhat unintuitive and predates the concept of ECMAScript modules, we would like to support a more ergonomic form if we feel it would be helpful.
Options
Bikeshedding time. 🚲 🏠
@from @import
/**
* @from "express"
* @import { Request, Response as CoolResponse } from
* @import Default
* @import * as ns
*/Pros
Cons
- Doesn't totally look like ESModule syntax which is just extra cognitive overhead.
ECMAScript Import-based
/**
* @import { x, y as z, default as Default } from "express"
*/Pros
- Nothing to learn if you already know ECMAScript syntax.
Cons
- Less optimal for completions
Issues with the Above
The options above don't make it explicit that only types are being imported. We could play around with keyword/tag placement (e.g. @importtype, @import type, etc.)
Background
#22158 tracks referencing types from a given module using JSDoc-style namepaths. Given that the syntax is somewhat unintuitive and predates the concept of ECMAScript modules, we would like to support a more ergonomic form if we feel it would be helpful.
Options
Bikeshedding time. 🚲 🏠
@from@importPros
@fromto precede named import clauses would be easier for completions (this is one of our oldest-duped requests Request for alternative import syntax to improve auto-complete experience #2371)importclauses@frombefore@importand vice versa.Cons
ECMAScript Import-based
Pros
Cons
Issues with the Above
The options above don't make it explicit that only types are being imported. We could play around with keyword/tag placement (e.g.
@importtype,@import type, etc.)