Closed
Description
Decorators on Class Expressions
- Goes against the policy we've had of investing more in decorators until progress
- Really wary of doing anything with decorators until we get a major update with major support on the proposal.
- Every feature adds
- size to the compiler
- potential bugs
- More complexity and logic that we're stuck with over time.
- "Stop digging the hole."
- There are workarounds, so we suggest that in the meantime.
- Parsing without "support"?
- Well now we have to do parsing.
- Don't know what that will look like.
- Conclusion: again, don't touch decorators until the proposal progresses.
Correcting Receivers on Calls
- Had to back out this change because it affects every single function call on every imported function.
foo.yadda()
->(0, foo.yadda)()
- Doesn't really impart a runtime performance cost, it imparts a compile-time performance cost.
- Tried to reuse a lot of nodes, still have to create a lot of new parenthesized nodes.
- Settled on "put it behind a flag".
- Haven't gotten a lot of negative feedback because a lot of people have been using
esnext
and a bundler.
- Haven't gotten a lot of negative feedback because a lot of people have been using
- Similar to
someFunc.name
. - Would be nice to have a level of preference around spec corner cases.
?.
and??
are unnecessarily complex for most users.
- Had several ideas around removing the performance cost.
- "Strict mode" like Babel's "loose mode"?
- Babel uses different transformations to do loose mode.
- We're more coarse-grained than that for the most part.
- No reason we have to architect it that way.
- Configurability would be great.
?.
or??
emit makes us upset.- Does this matter in the world of evergreen?
- ES3 is deadish
- ES5? Less clear.
downlevelIteration
useDefineForClassFields
- The current discussion positions TypeScript as "runtime breakage" - but changing the existing behavior is actually runtime breakage if you're relying on TS.
- Conclusion
- Try to avoid a flag.
- If not, come up with a consistent flag naming convention.
specEmitReceiver
? 😖specEmit*
as a prefix really is the higher order.strictEmit
?