fix(typescript-estree): the token value of an escaped identifier differs with espree #11116
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 on https://opencollective.com/typescript-eslint. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
View your CI Pipeline Execution ↗ for commit b0b6876.
☁️ Nx Cloud last updated this comment at |
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.
[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.
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.
[Testing] Nit: I'm a fan of having one thing under test per it() case. I think it would make sense to split each of these two-paired ones into two it()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.
my only concern here is that we're going to be doing a regex scan over every single Identifier 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')) {
return text;
}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? |
PR Checklist
Overview