Fix importHelpers incorrectly requiring tslib for native #private class members (#63728) - #64064
Open
Youssef Mansour (YoussefMansour9) wants to merge 1 commit into
Conversation
…ss members The check for private field helpers was incorrectly gated by ClassAndClassElementDecorators (pinned to ESNext), causing all dated targets (ES2022–ES2025) to require tslib even though native private fields are supported since ES2022 and no helper is ever emitted. Fixed in four locations: - checkPropertyAccessExpressionOrQualifiedName (private field get/set) - checkInExpression (private field 'in' checks) - setNodeLinksForPrivateIdentifierScope - getFirstTransformableStaticClassElement Fixes microsoft#63728
|
Youssef Mansour (@YoussefMansour9) please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
Copilot started reviewing on behalf of
Youssef Mansour (YoussefMansour9)
August 28, 2026 05:01
View session
Contributor
There was a problem hiding this comment.
Pull request overview
Updates private-field helper detection to avoid unnecessary tslib requirements for native private fields.
Changes:
- Removes broad decorator-target gating from four checker paths.
- Documents intended ES2022 and class-field behavior.
Suppressed comments (3)
tsc/internal/checker/checker.go:11371
- Standard class decorators can still force static private members to be transformed at ES2022+. In
esDecorators-classDeclaration-fields-staticPrivate(target=es2022).js, accesses to the class-decoratedD.#field1emit__classPrivateFieldGetand__classPrivateFieldSet(lines 58–59). With this condition,importHelpersno longer validates or resolves those helpers, so compilation can succeed and then emit imports that are missing or incompatible. Retain a decorator-specific branch limited to static private declarations in a standard-decorated class.
tsc/internal/checker/checker.go:13190 - The same decorator-specific lowering applies to brand checks on static private members of a class with a standard class decorator. Such a
#x in valueexpression is rewritten to__classPrivateFieldIneven at ES2022+, but this condition no longer registers the imported helper. Please preserve the helper check when the resolved private declaration is static and its containing class is transformed by standard decorators.
tsc/internal/checker/checker.go:11371 useDefineForClassFields: falsedoes not lower native private names at ES2022+; it only relocates field initializers. The existing ESNext baselineprivateNameWhenNotUseDefineForClassFieldsInEsNext(target=esnext).jspreserves every private access (for example lines 84–110), so no private helper is emitted. Keeping this branch means the reported TS2354 false positive still occurs for users who explicitly disableuseDefineForClassFields. Base the check on actual private-name lowering (plus the targeted standard-decorator/static-private case), and update the parallelinand collision conditions as well.
| willTransformPrivateElementsOrClassStaticBlocks := c.languageVersion < LanguageFeatureMinimumTarget.PrivateNamesAndClassStaticBlocks || c.languageVersion < LanguageFeatureMinimumTarget.ClassAndClassElementDecorators | ||
| // Private elements and class static blocks only need transformation before ES2022. | ||
| // Decorators (ClassAndClassElementDecorators) are a separate feature and should not gate private element transformation. | ||
| willTransformPrivateElementsOrClassStaticBlocks := c.languageVersion < LanguageFeatureMinimumTarget.PrivateNamesAndClassStaticBlocks |
Comment on lines
11370
to
11371
| if c.languageVersion < LanguageFeatureMinimumTarget.PrivateNamesAndClassStaticBlocks || | ||
| c.languageVersion < LanguageFeatureMinimumTarget.ClassAndClassElementDecorators || | ||
| !c.compilerOptions.GetUseDefineForClassFields() { |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The check for private field helpers was incorrectly gated by
ClassAndClassElementDecorators(pinned toESNext), causing all dated targets (ES2022–ES2025) to requiretslibeven though native private fields are supported since ES2022 and no helper is ever emitted.Root Cause
In
checker.go, the private field helper requirement was gated by:LanguageFeatureMinimumTarget.ClassAndClassElementDecoratorsis pinned toScriptTarget.ESNextbecause TC39 decorators have never been assigned to a dated ECMAScript edition. This made the condition unconditionally true for every dated target, regardless of whether the file uses decorators.Fix
Removed the decorator check from private field helper requirements in four locations:
checkPropertyAccessExpressionOrQualifiedName(lines 11361-11363) - private field get/setcheckInExpression(lines 13179-13181) - private fieldincheckssetNodeLinksForPrivateIdentifierScope(lines 10621-10623)getFirstTransformableStaticClassElement(line 10150)Now private fields only require helpers when:
PrivateNamesAndClassStaticBlocks)useDefineForClassFieldsis false (legacy class field semantics)Testing
Fixes #63728