Design Meeting Notes, 10/19/2022
DanielRosenwasser opened this issue ยท 2 comments
Codebase Module Migration
- Reorganized
Debug
into a namespace.- Allows typingsInstaller to tree-shake everything else.
- Boom, drops 5.5MB from our package size.
let
/const
- we're not going to bother downleveling that at the moment because- Our exports should (often) be
const
s - The other wins are so high that it's not an immediate priority.
- We can revisit at a later date
- Our exports should (often) be
- What is our new
target
?es2015
is safest, but is already kind of old.es2016
has**
, but not a huge pulles2017
hasasync
/await
- we don't use it reallyes2018
has async generators - but same as above.- Really, we just want to rougly guarantee that we'll continue to work in Node 10 (even though that's pretty old at this point too!)
- Should we sort the declarations in our
.d.ts
?- No.
- Things were intentionally colocated, we should preserve that.
- Giant import block problem
-
Auto-imports will keep tacking imports and mess with the line length.
-
Also, most import lists are on one line...
import { A, B, C } from "module";
or multiple imports per line
import { A, B, C, } from "module";
but
checker.ts
has a CRAZY number of imports, and we've done a mix to avoid the worst of both (long line length vs. thousands of import lines)import { A, B, C, D, E, F, G, H, I, } from "module";
-
So what do we want to do?
- Might be okay with just letting this go until we have a plan for the built-in formatter to understand line lengths.
- Using an external formatter after-the-fact.
-
Could put them at the bottom.
- Let's not be weird. Every language just does imports at the top. All JS devs do imports at the top.
- [[Editor's note]]: Yes, let's not be weird in our ~50K LoC file.
-
Maybe it's time to break parts of
checker.ts
out. -
Let's do nothing for now.
-
- Can we drop our internal
Map
types?- We dropped our shims in a recent version, nobody has complained yet.
- Can we just take/provide
Map
s andReadonlyMap
? - Maybe in the next version, but not necessarily in the initial PR.
๐
Enums Unifications and Improvements
-
Computed expressions on enum members would swap an enum over to a numeric enum, which preserves no information about the singleton types that each member represents.
- Meant you would get no control flow analysis on bindings who are assigned these enums.
-
PR changes numeric enums to still be literal-ish.
- When enums are computed and we cannot follow the computation, we now create an "opaque enum member".
- These are assignable to
number
and and the containing enum, but nothing becomes assignable to it.
- These are assignable to
- When enums are computed and we cannot follow the computation, we now create an "opaque enum member".
-
Enums that contain these numeric members still allow assignments from any other number to support the bitflags case.
-
PR also allows
- concatenation from template string expressions.
- references to literal-initialized
const
variables.
-
Most people are just using union enums. Not a huge performance effect. Things in our perf suite were not affected. Identified one questionable issue in VS Code. 4 new errors in our compiler. One is #9998.
-
Aside - lots of cases where people want to extend enums (#17592)
enum E10 { A, B, C, } enum E11 { ...E10, D, E, }
- No good way to really emulate that.
- Almost 600 upvotes on our issue tracker
- Doing more in the enum space feels iffy - is runtime behavior, but is runtime behavior that TypeScript already kind of has made.
- Some things in the pipeline for ECMAScript... though that proposal would be radically different anyway.
- Our enums have relatively little value for JS users - it's the same as an object literal for the most part.
- ES proposal does intend to keep some of TS behavior.
- "Scalar enums"
- We don't feel good treading this ground even if TypeScript has set a lot of precedent - lots of occasions where the "simple obvious" language feature has issues with what actually lands in ECMAScript.
- No good way to really emulate that.
[[Editor's note]]: Yes, let's not be weird in our ~50K LoC file.
Just to clarify, the ES syntax we decided on was ES2018, what Node 10 supports. That leaves our codebase without any downleveing helpers.