You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
The text was updated successfully, but these errors were encountered:
Very frustrated about the decorators decision. I do understand your reasoning though.
Just curious - the same problem will remain with the emerging ES decorators spec? It will also not be possible to use ES spec decorators in class expressions? It feels like this PR is actually future-proof.
Personally for me this decision means I'll have to stick with the abandoned TS branch, you can imagine what it's like. And thing is, a workaround for this issue exists, but it breaks the declaration files generation. Shouldn't that be addressed finally.
Perhaps the #42198 PR was closed prematurely. Better to keep it may be, because if the ES spec will say decorators are applicable for class expressions, it can be re-used. Otherwise someone will have to repeat the work already done.
Decorators on Class Expressions
#42198
#44237 (comment)
Correcting Receivers on Calls
#35877
foo.yadda()
->(0, foo.yadda)()
esnext
and a bundler.someFunc.name
.?.
and??
are unnecessarily complex for most users.?.
or??
emit makes us upset.downlevelIteration
useDefineForClassFields
specEmitReceiver
? 😖specEmit*
as a prefix really is the higher order.strictEmit
?The text was updated successfully, but these errors were encountered: