Description
A Stricter Subtype Relationship
-
Issue: Destructuring of optional fn + default function value gets signature from the value #35414
-
PR: Increase selectivity of subtype relationship for signatures #35659
-
We have this thing where we perform union subtype reduction - reducing constituents of unions when a union contains a supertype.
-
But we sort unions by a type IDs, but that's not a "stable" ordering.
- Our current subtype relationship contains "ties" though - several types can be subtypes of each other.
- First type ID wins, so if you reorder declarations/instantiations in your program, the behavior changes! That's undesirable.
-
The solution is to avoid places where types can "tie" in which types are supertypes.
-
It's strictly a good thing in subtype reduction, but it can have effects elsewhere.
- One effect that's measured is that two constituents might be preserved in a reduced union (something we're willing to take).
- Additionally, because of our union merging, we might have different effects on which signatures are present.
- Also seeing differences in overload resolution because overload resolution does a subtype pass.
- Historical reasons for saying
any
is not the best type to choose from.
- Historical reasons for saying
-
These changes introduce a lot of potential breaks elsewhere, so we introduced a separate relationship to the compiler.
- Ideally we'd use this new subtype relationship everywhere, but we don't want to impact too much.
-
Example breaks seem "good" but hard to deal with.
-
Could we imagine a strict mode that uses the strict subtype relationship?
- Maybe! It's worth thinking about.
-
As a compiler writer, what relationship do I use?
- [[rules that went by too fast, but you can consult with the team]]
-
Conclusion
- Turn it on just for subtype reduction.
- Try it out everywhere, see what breaks, see if it can fit under a strict mode - i.e.
--strictSubtypes
but with a better name.
Assume Changes Only Affect Dependencies
-
Issue: tsc --watch --incremental recompiles are too slow for use with VS Code source #33329
-
VS Code has a tool called
gulp-tsb
- Its
--watch
is faster thantsc --watch
because it assumes only direct dependencies will be affected. - Common case is that they won't, so it's a nice optimization to iterate quickly, but it's definitely very sloppy/inaccurate.
- Takes incremental check time down from 14 seconds to 1 second.
- Its
-
[[Bikeshed on name]]
Type-Only Imports/Exports
- Scenarios
- Re-export a type in
isolatedModules
- Stop eliding imports when I do DI
- Re-export a type in
- Behavior
- Changed default emit behavior to preserve imports
- Flag to opt in to the old behavior
- Effect
- Can increase bundle sizes 👎
- Hard to determine where to fix 👎
- Runtime behavior might break, or you might not notice the change at all 👎
- Proposals to mitigate issues
- Proposal 1
- Add error on regular imports used only as types.
- Disable error via a flag.
- Proposal 2
- Keep today's emit behavior.
- Opt into preserved imports via a flag
- Optionally enable this in
tsc --init
- Optionally add a flag to force type-only imports for identifiers used only as types
- Proposal 3
- Transition plan
- Proposal 1
- 3 years from now where do we want to be?
- Can we remove things from the import list under
isolatedModules
currently?- Yes
- Anecdotal from Wesley: when I transitioned our unit tests into modules, there were a lot of issues because our unittests were only being included via type-imports.
- Experience is that elision has undesirable behavior
- This is a very big breaking change even if you phase it over several releases.
- People are in an unknown state of what they want - only make noise (i.e. give an error) when the intent isn't clear.
- Can we remove things from the import list under
- Can this be a strict mode flag?
- Strict flags have never affected emit.
- Could this be mitigated with a tristate flag?
- Well then what's the default?
- Conclusion:
- The safer proposal 2
- Leaves our options open
- Implement option as a tristate
preserve
be default intsc --init
- Send PRs to 3rd party tools
- Turn it on in scaffolding tools
- Babel
- Need to signal to the team, maybe need a flag (@hzoo).
- The safer proposal 2
Use Getters for Live Bindings
- Turns out even we were giving people "wrong" exports because of this.
- Let's do it.