fix(turbopack): patch lightningcss to handle unparseable @container conditions - #98297
Open
Larslllllll wants to merge 1 commit into
Open
fix(turbopack): patch lightningcss to handle unparseable @container conditions#98297Larslllllll wants to merge 1 commit into
Larslllllll wants to merge 1 commit into
Conversation
…onditions
When error_recovery is enabled (used by Turbopack), the lightningcss CSS parser
would fail on valid CSS containing `@container <name> { ... }` named container
queries, reporting "Unexpected end of input".
This patches lightningcss to use ContainerCondition::Unknown for unparseable
conditions when error_recovery is enabled, allowing the CSS to be parsed
despite unsupported @container syntax.
Fixes vercel#98261
| # Patch lightningcss to fix @container named query parsing with error_recovery | ||
| # This allows @container scroll-content { ... } to be parsed without erroring | ||
| # when error_recovery is enabled (Turbopack uses error_recovery: true). | ||
| lightningcss = { git = "https://github.com/Larslllllll/lightningcss.git", branch = "fix/container-error-recovery", tag = "v1.0.0-alpha.72.fix" } |
Contributor
There was a problem hiding this comment.
Suggested change
| lightningcss = { git = "https://github.com/Larslllllll/lightningcss.git", branch = "fix/container-error-recovery", tag = "v1.0.0-alpha.72.fix" } | |
| lightningcss = { git = "https://github.com/Larslllllll/lightningcss.git", tag = "v1.0.0-alpha.72.fix" } |
The lightningcss [patch.crates-io] git entry specifies both branch and tag, which Cargo rejects as an ambiguous source specification, breaking all workspace Cargo commands.
This file contains hidden or 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
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.
Summary
Turbopack's CSS parser (lightningcss) fails to build projects that use CSS containing
@container <name> { ... }named container queries, reporting:This affects real-world CSS from libraries like
nhsuk-frontend.Root Cause
In
lightningcss/src/parser.rs, the@containerrule parsing has this error handling:When parsing
@container scroll-content { ... },input.is_exhausted()isfalse(because{is waiting), so the error is propagated instead of being handled gracefully.Fix
Check
self.options.error_recoverybefore returning the error. When error recovery is enabled (which Turbopack uses), useContainerCondition::Unknownfor unparseable conditions:The fix is in a patched fork of lightningcss: https://github.com/Larslllllll/lightningcss/tree/fix/container-error-recovery
A PR has been submitted to upstream: parcel-bundler/lightningcss#1330
Fixes #98261