Description
importsNotUsedAsValues: preserve-exact
-
People expect
import fs from "fs"
to compile toimport fs from "fs"
inimportsNotUsedAsValues: 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.
- Same as
-
The PR stops short of some of the work from last time.
- Specifically,
type
modifiers on imports.-
Would erase away those named imports.
-
How does that play with when you have a default?
import type fs, { yadda } from "yadda";
- Ambiguous? Maybe disambiguate with
type: fs
- Not clear that that actually helps at all.
- Ambiguous? Maybe disambiguate with
-
- Specifically,
-
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.
- What is the mode that will allow you to be maximally compatible with compilers?
-
Meaningful use case:
import
means valueimport
,import type
means erased import.-
But how do you deal with
export { A }
?- Do you need to write
export type { A }
? - Feels different.
- Do you need to write
-
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
vsimport 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.