-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge 'decorators' into 'modifiers' on various nodes #49089
Conversation
ea48336
to
1cf55ef
Compare
@typescript-bot perf test |
Heya @rbuckton, I've started to run the perf test suite on this PR at 1cf55ef. You can monitor the build here. Update: The results are in! |
@rbuckton Here they are:Comparison Report - main..49089
System
Hosts
Scenarios
Developer Information: |
@typescript-bot perf test |
Heya @rbuckton, I've started to run the perf test suite on this PR at c7fce15. You can monitor the build here. Update: The results are in! |
c7fce15
to
01f9749
Compare
@rbuckton Here they are:Comparison Report - main..49089
System
Hosts
Scenarios
Developer Information: |
Performance is fairly close. There's unfortunately a little bit more megamorphism due to Decorator and Modifier being in the same array, but the impact has been fairly minimal (less than a tenth of a second in total compile time). The upside is that memory usage dropped across the board, and is especially noticeable in xstate. |
# Conflicts: # src/compiler/checker.ts # src/compiler/transformers/ts.ts # src/compiler/utilities.ts
0f71949
to
a906d6f
Compare
a906d6f
to
d6e4576
Compare
# Conflicts: # src/testRunner/unittests/tsbuild/helpers.ts
…tions are printed
Got slightly ahead of myself with the merge, but I've fixed the test failure in |
I discovered that this breaks e.g. tsutils as NodeArray isn't compatible with ModifiersArray which is expected here. I see that the plan is to make it a soft failure in 4.8, do you also have a suggestion on how to make the code compatible with both 4.7 and 4.8? |
Whilst investigating typescript-eslint/typescript-eslint#5496 I locally upgraded our codebase to v4.8.1-rc and then did not see any relevant TS errors - it wasn't until I manually inspected the code that I noticed the VSCode strike-out decoration on the deprecated members that I found out about the change. From the perspective of an AST consumer - deprecating the now dead properties instead of removing them entirely is a bit of a problem. We'll have to manually audit our entire codebase to find the code that's now broken. |
Update tsconfig-paths hook to be compatible with how `updateExportDeclaration` now works in typescript 5. This is from microsoft/TypeScript#49089
Update tsconfig-paths hook to be compatible with how `updateExportDeclaration` now works in typescript 5. This is from microsoft/TypeScript#49089
Update tsconfig-paths hook to be compatible with how `updateExportDeclaration` now works in typescript 5. This is from: microsoft/TypeScript#49089
Decorators are now placed on `modifiers` on TypeScript's syntax trees. Passing decorators separately has been deprecated since v4.8 and removed completely in v5. https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-8.html#decorators-are-placed-on-modifiers-on-typescripts-syntax-trees microsoft/TypeScript#49089
Decorators are now placed on `modifiers` on TypeScript's syntax trees. Passing decorators separately has been deprecated since v4.8 and removed completely in v5. https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-8.html#decorators-are-placed-on-modifiers-on-typescripts-syntax-trees microsoft/TypeScript#49089
This merges the
decorators
field onNode
into themodifiers
field in preparation for eventual support for Decorators Stage 3. This is necessary since the version of the Decorators proposal that advanced parses class decorators after theexport
anddefault
keywords, which is incompatible with our current AST andNodeFactory
methods.To avoid a large amount of complex overloads, we've currently opted to change thedecorators
parameter on variousNodeFactory
API methods to only acceptnull
(which we generally don't use in the compiler). Calling the existingNodeFactory
API methods with a value fordecorators
that is notnull
will result in a deprecation warning, but should otherwise work for the time being. To avoid a major runtime breaking API change in 4.x releases, we likely won't remove thedecorators
parameter entirely until 5.0.NOTE: After some consideration, I've amended the approach above to remove the
decorators
parameter entirely from the main API and only support it through overloads via deprecatedCompat.This also reorganizes the deprecatedCompat project for easier maintenance, and moves a few deprecated APIs out of compiler to reduce overhead in tsc.js.
NOTE TO REVIEWERS: I've added a large number of reviewers since this pertains to the public API so I can get more eyes on this.