Move legacy decorators into separate transform #48669
Conversation
typescript-bot
added
Author: Team
For Uncommitted Bug
| 3 > ^^^ | ||
| 4 > ^^^^^^^^^^ | ||
| 5 > ^ | ||
| 3 > ^^^^^^^^^^^^^ |
There was a problem hiding this comment.
This shouldnt have changed right? i mean we do want = as separate thing in sourcemap ?
There was a problem hiding this comment.
This is a consequence of performing transforms in two steps where we first remove the modifiers (in the ts transform), and then remove the decorators (in the legacyDecorators transform). It's not the = that is mapped here, but rather the start of the function expression that is no longer mapped to the start of the private modifier since that modifier no longer exists when the decorators transform is run. I debated accepting this change, but modifiers aren't a valid position for an inline breakpoint so this doesn't seem to affect the debug experience.
There was a problem hiding this comment.
It turns out the information is available, since the decorators and modifiers arrays exist and have a pos/end but are empty. The issue is that moveRangePastDecorators and moveRangePastModifiers only use the end of a NodeArray if the array isn't empty. I may be able to change that to get the necessary information to insert a valid source map position here.
There was a problem hiding this comment.
I've pushed up a change to address this. There are still changes to the sourcemap emit, but these changes should be an improvement as the mappings are more consistent.
rbuckton
force-pushed
the
legacyDecorators
branch
from
dc52855 to
2ca0e72
Compare
rbuckton
force-pushed
the
legacyDecorators
branch
from
2ca0e72 to
50fa541
Compare
|
@sheetalkamat can you take another look? |
|
That would be my preference yes. The sooner we can get feedback on any issues with the API changes, the better. |
There was a problem hiding this comment.
Looks good to me. @sheetalkamat can you take another look too?
This moves the portion of the
tstransform that handles decorators to a separate transformer to pave the way for eventual support for native ECMAScript decorators now that the proposal has reached Stage 3.