Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.8k
fix(typescript-estree): the token value of an escaped identifier differs with espree#11116
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
fix(typescript-estree): the token value of an escaped identifier differs with espree#11116
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Thanks for the PR,@dbarabashh! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently onhttps://opencollective.com/typescript-eslint. |
netlifybot commentedApr 29, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
✅ Deploy Preview fortypescript-eslint ready!
To edit notification comments on pull requests, go to yourNetlify site configuration. |
nx-cloudbot commentedApr 29, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
codecovbot commentedApr 29, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@## main #11116 +/- ##======================================= Coverage 90.84% 90.84% ======================================= Files 497 497 Lines 50320 50332 +12 Branches 8311 8315 +4 =======================================+ Hits 45714 45726 +12 Misses 4591 4591 Partials 15 15
Flags with carried forward coverage won't be shown.Click here to find out more.
🚀 New features to boost your workflow:
|
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
return String.fromCodePoint(codePoint); | ||
}, | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
[Question] I'm not very familiar with these\u
shenanigans and don't particularly feel a drive to be. Is there a standard package that does this? If not, maybe it would make sense to make one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
LGTM, thanks! 🚀
I would definitely prefer someone like@bradzacher who's more familiar with text parsing review. But from my less-than-expert perspective this all looks great.
expect(unescapeUnicodeIdentifier('\\u00ZZ')).toBe('\\u00ZZ'); | ||
expect(unescapeUnicodeIdentifier('\\u{ZZ}')).toBe('\\u{ZZ}'); | ||
}); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
[Testing] Nit: I'm a fan of having one thing under test perit()
case. I think it would make sense to split each of these two-paired ones into twoit()
s. But I wouldn't block on it, this file already doesn't align to that (and even more so in existing code!).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
my only concern here is that we're going to be doing a regex scan over every singleIdentifier
in every single file we parse just so that we can potentially catch one specific edge-case that (a) likely isn't present in 99.9999% of code and (b) likely doesn't impact anyone's lint rules...
acorn gets away with producing a token with the non-encoded character because it is a true parser -- it derives the AST from the tokens it produces.
Truth be told -- I'm honestly not completely sold on us landing this to align with acorn/espree. WDYT @typescript-eslint/triage-team?
@bradzacher what if add a check before running the regex? Something like: if(!text.includes('\\u')){returntext;} this way we keep the compatibility but only run the expensive regex when there's actually a unicode escape. Should solve the performance concern since 99.9% of identifiers will take the fast path. any thoughts? |
Uh oh!
There was an error while loading.Please reload this page.
PR Checklist
Overview