Description importsNotUsedAsValues: preserve-exact
#44137
People expect import fs from "fs" to compile to import fs from "fs" in importsNotUsedAsValues: preserve
We don't - we just preserve the import itself.
Came up offhandedly.
In places like Svelte, they eval some stuff, do a bunch of hacks to ensure that the imports stick around.
The idea: new flag.
Same as importsNotUsedAsValues: error.
No, that's only an error if you never import a value.
The PR stops short of some of the work from last time.
Specifically, type modifiers on imports.
Requires es2015+ as a module target.
Doesn't make sense for if you're mixing CJS/ESM.
The "eval" thing doesn't quite work for our emit anyway.
How does tooling work with this?
We currently don't "promote" a type import to a value import.
A lot of people would prefer not to - sometimes people are using this mode defensively to prevent themselves from bundling more.
As long as we can improve in the future and have room.
This rule applies to both imports and exports
import { foo } from "./module.js" ;
foo ( ) ;
interace Thing { }
export { Thing } ;
Getting a read for how these options interact is hard .
What is the mode that will allow you to be maximally compatible with compilers?
--isolatedModules
But that won't change things.
Meaningful use case: import means value import, import type means erased import.
But how do you deal with export { A }?
Do you need to write export type { A }?
Feels different.
Okay, harder case:
import Yadda from "yadda" ;
export { Yadda } ;
Okay, but one is local, we know exactly what it'll be.
Not consistent with "leave my imports and exports alone".
We seem to feel that a local export {} is exempt from elision rules because the constructs are all local.
If TypeScript was a greenfield project, this is probably what our default would be.
Would it be?
Would we use this ourselves?
Managing import vs import type is very annoying.
Not super big on giving an error in ES5.
Need to think through this a bit more, come up with a coherent write-up.
Reactions are currently unavailable
You can’t perform that action at this time.
importsNotUsedAsValues: preserve-exact#44137
People expect
import fs from "fs"to compile toimport fs from "fs"inimportsNotUsedAsValues: preserveCame up offhandedly.
In places like Svelte, they
evalsome stuff, do a bunch of hacks to ensure that the imports stick around.The idea: new flag.
importsNotUsedAsValues: error.The PR stops short of some of the work from last time.
typemodifiers on imports.Would erase away those named imports.
How does that play with when you have a default?
type: fsRequires
es2015+ as a module target.How does tooling work with this?
This rule applies to both imports and exports
Getting a read for how these options interact is hard.
--isolatedModulesMeaningful use case:
importmeans valueimport,import typemeans erased import.But how do you deal with
export { A }?export type { A }?Okay, harder case:
Okay, but one is local, we know exactly what it'll be.
Not consistent with "leave my imports and exports alone".
We seem to feel that a local
export {}is exempt from elision rules because the constructs are all local.If TypeScript was a greenfield project, this is probably what our default would be.
importvsimport typeis very annoying.Not super big on giving an error in ES5.
Need to think through this a bit more, come up with a coherent write-up.