compiler: Workaround Babel bug with unicode in jsx string attrs #29141
Conversation
This file contains 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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
CLA Signed
React Core Team
|
Comparing: 3f1436c...86424b7 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
poteto
approved these changes
May 17, 2024
| function Component() { | ||
| return ( | ||
| <Post | ||
| author="potetotes" |
There was a problem hiding this comment.
wow my first mention in the tests! so honored 🤣
poteto
added a commit
that referenced
this pull request
Jun 20, 2024
This PR extends the previous logic added in #29141 to also account for other kinds of non-ascii characters such as `\n`. Because these control characters are individual special characters (and not 2 characters `\` and `n`) we match based on unicode which was already being checked for non-Latin characters. This allows control characters to continue to be compiled equivalently to its original source if it was provided in a JsxExpressionContainer. However note that this PR does not convert JSX attributes that are StringLiterals to JsxExpressionContainer, to preserve the original source code as it was written. Alternatively we could always emit a JsxExpressionContainer if it was used in the source and not try to down level it to some other node kind. But since we already do this I opted to keep this behavior. ghstack-source-id: 42a80bb1c8bc6d655b8b96bd5f967d141ee7b466 Pull Request resolved: #29997
poteto
added a commit
that referenced
this pull request
Jun 20, 2024
This PR extends the previous logic added in #29141 to also account for other kinds of non-ascii characters such as `\n`. Because these control characters are individual special characters (and not 2 characters `\` and `n`) we match based on unicode which was already being checked for non-Latin characters. This allows control characters to continue to be compiled equivalently to its original source if it was provided in a JsxExpressionContainer. However note that this PR does not convert JSX attributes that are StringLiterals to JsxExpressionContainer, to preserve the original source code as it was written. Alternatively we could always emit a JsxExpressionContainer if it was used in the source and not try to down level it to some other node kind. But since we already do this I opted to keep this behavior. Partially addresses #29648. ghstack-source-id: 42a80bb1c8bc6d655b8b96bd5f967d141ee7b466 Pull Request resolved: #29997
poteto
added a commit
that referenced
this pull request
Jun 20, 2024
This PR extends the previous logic added in #29141 to also account for other kinds of non-ascii characters such as `\n`. Because these control characters are individual special characters (and not 2 characters `\` and `n`) we match based on unicode which was already being checked for non-Latin characters. This allows control characters to continue to be compiled equivalently to its original source if it was provided in a JsxExpressionContainer. However note that this PR does not convert JSX attributes that are StringLiterals to JsxExpressionContainer, to preserve the original source code as it was written. Alternatively we could always emit a JsxExpressionContainer if it was used in the source and not try to down level it to some other node kind. But since we already do this I opted to keep this behavior. Partially addresses #29648. ghstack-source-id: 965cf50df43ff8f8211990223ef1ecb2dfdcfec7 Pull Request resolved: #29997
poteto
added a commit
that referenced
this pull request
Jun 20, 2024
This PR extends the previous logic added in #29141 to also account for other kinds of non-ascii characters such as `\n`. Because these control characters are individual special characters (and not 2 characters `\` and `n`) we match based on unicode which was already being checked for non-Latin characters. This allows control characters to continue to be compiled equivalently to its original source if it was provided in a JsxExpressionContainer. However note that this PR does not convert JSX attributes that are StringLiterals to JsxExpressionContainer, to preserve the original source code as it was written. Alternatively we could always emit a JsxExpressionContainer if it was used in the source and not try to down level it to some other node kind. But since we already do this I opted to keep this behavior. Partially addresses #29648. ghstack-source-id: e5f3ca7f378c331de024e5118d5790f9b92d03a3 Pull Request resolved: #29997
poteto
added a commit
that referenced
this pull request
Jun 20, 2024
This PR extends the previous logic added in #29141 to also account for other kinds of non-ascii characters such as `\n`. Because these control characters are individual special characters (and not 2 characters `\` and `n`) we match based on unicode which was already being checked for non-Latin characters. This allows control characters to continue to be compiled equivalently to its original source if it was provided in a JsxExpressionContainer. However note that this PR does not convert JSX attributes that are StringLiterals to JsxExpressionContainer, to preserve the original source code as it was written. Alternatively we could always emit a JsxExpressionContainer if it was used in the source and not try to down level it to some other node kind. But since we already do this I opted to keep this behavior. Partially addresses #29648. ghstack-source-id: 552bd447ceacc9c8802f13e637f1cca61c3f7831 Pull Request resolved: #29997
poteto
added a commit
that referenced
this pull request
Jun 20, 2024
This PR extends the previous logic added in #29141 to also account for other kinds of non-ascii characters such as `\n`. Because these control characters are individual special characters (and not 2 characters `\` and `n`) we match based on unicode which was already being checked for non-Latin characters. This allows control characters to continue to be compiled equivalently to its original source if it was provided in a JsxExpressionContainer. However note that this PR does not convert JSX attributes that are StringLiterals to JsxExpressionContainer, to preserve the original source code as it was written. Alternatively we could always emit a JsxExpressionContainer if it was used in the source and not try to down level it to some other node kind. But since we already do this I opted to keep this behavior. Partially addresses #29648. ghstack-source-id: 032700cc4ddb191e81af7c611b4d4345b02568a2 Pull Request resolved: #29997
poteto
added a commit
that referenced
this pull request
Jun 20, 2024
This PR extends the previous logic added in #29141 to also account for other kinds of non-ascii characters such as `\n`. Because these control characters are individual special characters (and not 2 characters `\` and `n`) we match based on unicode which was already being checked for non-Latin characters. This allows control characters to continue to be compiled equivalently to its original source if it was provided in a JsxExpressionContainer. However note that this PR does not convert JSX attributes that are StringLiterals to JsxExpressionContainer, to preserve the original source code as it was written. Alternatively we could always emit a JsxExpressionContainer if it was used in the source and not try to down level it to some other node kind. But since we already do this I opted to keep this behavior. Partially addresses #29648. ghstack-source-id: ecc61c9f0bece90d18623b3c570fea05fbcd811a Pull Request resolved: #29997
poteto
added a commit
that referenced
this pull request
Jun 21, 2024
This PR extends the previous logic added in #29141 to also account for other kinds of non-ascii characters such as `\n`. Because these control characters are individual special characters (and not 2 characters `\` and `n`) we match based on unicode which was already being checked for non-Latin characters. This allows control characters to continue to be compiled equivalently to its original source if it was provided in a JsxExpressionContainer. However note that this PR does not convert JSX attributes that are StringLiterals to JsxExpressionContainer, to preserve the original source code as it was written. Alternatively we could always emit a JsxExpressionContainer if it was used in the source and not try to down level it to some other node kind. But since we already do this I opted to keep this behavior. Partially addresses #29648. ghstack-source-id: ecc61c9f0bece90d18623b3c570fea05fbcd811a Pull Request resolved: #29997
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.
Stack from ghstack (oldest at bottom):
Workaround for a bug in older versions of Babel, where strings with unicode are incorrectly escaped when emitted as JSX attributes, causing double-escaping by later processing.
Closes #29120
Closes #29124