-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
PostCSS style transformation: fail gracefully instead of throwing an error #56093
PostCSS style transformation: fail gracefully instead of throwing an error #56093
Conversation
@strarsis I'd appreciate a review here. |
Size Change: +83 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
@zaguiini: Great addition! 👍 |
].filter( Boolean ) | ||
).process( css, {} ).css; // use sync PostCSS API | ||
} catch ( error ) { | ||
if ( ! ( error instanceof CssSyntaxError ) ) { |
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.
I'm not familiar enough with postCSS to know when an error is not a CssSyntaxError. In what scenario this condition will be true and the console warn be useful?
@@ -4,6 +4,28 @@ | |||
import transformStyles from '../transform-styles'; | |||
|
|||
describe( 'transformStyles', () => { | |||
it( 'should not throw error in case of invalid css', () => { |
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.
This test is welcome but it actually doesn't not test what was broken in the UI of the custom CSS advanced panel. It just tests the return value is null
when there is a CSS error. It doesn't make sure the UI works as expected.
Quickly tested and it does fix the issue. I'd recommend to add an E2E test for the feature that was actually broken in
|
On a related note: Previously, when there was an error in the CSS added to the textarea, the console warn gave some hint on the type of error: We could argue that wasn't that useful to average users. However, now there won't be anything in the console. I read there are nice ways to handle the error output, see https://postcss.org/docs/postcss-runner-guidelines#output Input:
Dupming this to the console: That would provide some more useful information to users. It would also highlight which line(s) of the source CSS errored: |
Thanks. @afercia I do not have the bandwidth to add the E2E test, so the best I can do right now is to fix the unit test and merge this PR. Would you be able to add the E2E test as a follow-up PR? |
ce181e0
to
6fb144f
Compare
@afercia, we have that now: I have updated the tests and rebased the branch with |
6fb144f
to
bf10159
Compare
@zaguiini I'd really love to change the current red icon to a standard notice because the red icon isn't accessible at all. I will create a new issue and link to this PR as a reminder that an E2E test should be added as well. I like the |
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.
Yes, this fixes the unexpected exceptions thrown by transformStyles
. The calling code expects a null
return value in case of error.
…error (#56093) * PostCSS style transformation: fail gracefully instead of throwing error * Display better warning messages
…error (#56093) * PostCSS style transformation: fail gracefully instead of throwing error * Display better warning messages
Closes #56082.
What?
#49521 introduces a regression in which invalid CSS throws an error. This PR fixes the problem by letting the transformation fail gracefully.
Why?
#49521 changed the internal CSS transformer to fix a couple of issues, but invalid CSS handling was not exhaustively tested.
How?
I'm wrapping the transformation function with a try-catch block and returning null in case it fails to parse the CSS.
Testing Instructions
Follow the instructions in #56082.