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
The module you're importing has a type, but also has side-effects.
preserve fixes this.
The named import is dropped, but the import statement is retained for side-effects.
preserveValueImports
Default is false
Wouldn't it be simpler to have a mode where whatever you write is what you get, and the only things that get dropped are type imports?
So import { blah, type foo } from "module" -> import { blah } from "module"
So import { type foo } from "module" -> import "module"
Technically this mode already exists - when you combine importsNotUsedAsValues: preserve and preserveValueImports: true with isolatedModules: true.
What's the const enum behavior?
Seems like simplifying is good, and this is what we wanted to ship originally - but are we forgetting the original use-cases? Also, we would be sending our users a lot of confusion/mixed messages.
Angular.js 1.x was a pretty big motivation.
Error mode was possibly a mistake - trying to signal "this is an unnecessary value import."
Maybe this should have been a lint rule.
There is positive feedback about deprecating the old options, providing a new one.
Second part of this proposal prohibits ESM syntax when targeting other module systems.
CJSish systems would need
Importing
importfs= require("fs");
exports need to be export = { /* some object*/ }
Tradeoff - named imports in import {} = require(...) aren't supported.
Anecdotally, issues in CJS/ESM interop in nodenext are horrible - the resolution works, but the types inferred from the interop are extremely confusing.
We have consensus on the first part, not the second part being part of the same flag.
Require Literal Types to Have Value Overlap in Assignability with Enums
We think there are no issues in principle - but implementation consults the declared type which is inappropriate. You can end up with one of these unknowns in different ways
Discussion should follow outside of the meeting.
The text was updated successfully, but these errors were encountered:
Verbatim Import Syntax
#51479
importsNotUsedAsValues
remove
import
preserve
fixes this.preserveValueImports
false
type
imports?import { blah, type foo } from "module"
->import { blah } from "module"
import { type foo } from "module"
->import "module"
importsNotUsedAsValues: preserve
andpreserveValueImports: true
withisolatedModules: true
.Importing
export
s need to beexport = { /* some object*/ }
Tradeoff - named imports in
import {} = require(...)
aren't supported.Anecdotally, issues in CJS/ESM interop in nodenext are horrible - the resolution works, but the types inferred from the interop are extremely confusing.
Require Literal Types to Have Value Overlap in Assignability with Enums
#51561
Today this is the situation in our
main
branch:0
-likeNone
value.enum E { Foo = Math.random() }
allows it to be comparable to everything else.Narrowing
unknown
-Originating{}
Values withinstanceof
#51014
Playground Link
unknown
s in different waysThe text was updated successfully, but these errors were encountered: