Add internal export of CSS Parser used to transform editor styles #42728
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
fabiankaegy
added
[Package] Block editor
|
Size Change: +8 B (0%) Total Size: 1.26 MB
ℹ️ View Unchanged
|
Mamaduka
reviewed
Jul 27, 2022
Co-authored-by: George Mamadashvili <[email protected]>
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.
What?
Export the internal fork of the CSS parser from
reworkcss/cssso that other tooling can use it in the meantime till all the issues outlined in #40444 are solved for.Why?
WordPress uses a forked version of reworkcss/css in order to parse the editor CSS stylesheet. You can find the fork here in the codebase.
gutenberg/packages/block-editor/src/utils/transform-styles/ast/parse.js
Lines 3 to 10 in ddd61e4
A few issues with this parser are currently getting tracked in #40444.
Because of these issues, it can currently easily happen that a CSS rule that is technically valid causes the parser to choke and therefore leads to an unstyled editor experience. Since the CSS that is output by build tools like webpack is technically valid these issues often only show themselves in the actual production build when the files are minified etc.
Whilst the end goal should always be to improve the parser to fail more gracefully and not choke on valid CSS, it would be great to allow for external tooling to catch any problematic CSS in their build step instead of only seeing these issues in production.
Closing: #42727
How?
Add the parser function to the top level exports of the
@wordpress/block-editorpackage.Testing Instructions
Not applicable