You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With this, there are some new features around the imports.
Currently, they are not support by vsc-sort-imports and break the code.
For Example, some necessary changes from the TypeScript Docs:
type Modifiers on Import Names
// Which of these is a value that should be preserved? tsc knows, but `ts.transpileModule`,// ts-loader, esbuild, etc. don't, so `isolatedModules` issues an error.import{someFunc,BaseType}from"./some-module.js";// ^^^^^^^^// Error: 'BaseType' is a type and must be imported using a type-only import// when 'preserveValueImports' and 'isolatedModules' are both enabled.
When these options are combined, we need a way to signal when an import can be legitimately dropped. TypeScript already has something for this with import type:
This works, but it would be nice to avoid two import statements for the same module. That’s part of why TypeScript 4.5 allows a type modifier on individual named imports so that you can mix and match as needed.
In the above example, BaseType is always guaranteed to be erased and someFunc will be preserved under preserveValueImports, leaving us with the following code:
TypeScript 4.5 supports an ECMAScript proposal for import assertions. This is a syntax used by runtimes to make sure that an import has an expected format.v
The contents of these assertions are not checked by TypeScript since they’re host-specific, and are simply left alone so that browsers and runtimes can handle them (and possibly error).
// TypeScript is fine with this.// But your browser? Probably not.importobjfrom"./something.json" assert {type: "fluffy bunny"};
Dynamic import() calls can also use import assertions through a second argument.
TypeScript 4.5 is released.
With this, there are some new features around the imports.
Currently, they are not support by
vsc-sort-imports
and break the code.For Example, some necessary changes from the TypeScript Docs:
type
Modifiers on Import NamesWhen these options are combined, we need a way to signal when an import can be legitimately dropped. TypeScript already has something for this with
import type
:This works, but it would be nice to avoid two import statements for the same module. That’s part of why TypeScript 4.5 allows a
type
modifier on individual named imports so that you can mix and match as needed.In the above example,
BaseType
is always guaranteed to be erased andsomeFunc
will be preserved underpreserveValueImports
, leaving us with the following code:Import Assertions
TypeScript 4.5 supports an ECMAScript proposal for import assertions. This is a syntax used by runtimes to make sure that an import has an expected format.v
The contents of these assertions are not checked by TypeScript since they’re host-specific, and are simply left alone so that browsers and runtimes can handle them (and possibly error).
Dynamic
import()
calls can also use import assertions through a second argument.The expected type of that second argument is defined by a new type called
ImportCallOptions
, and currently only accepts anassert
property.The text was updated successfully, but these errors were encountered: