Skip to content

fix(turbopack): patch lightningcss to handle unparseable @container conditions - #98297

Open
Larslllllll wants to merge 1 commit into
vercel:canaryfrom
Larslllllll:fix/lightningcss-container-error-recovery
Open

fix(turbopack): patch lightningcss to handle unparseable @container conditions#98297
Larslllllll wants to merge 1 commit into
vercel:canaryfrom
Larslllllll:fix/lightningcss-container-error-recovery

Conversation

@Larslllllll

Copy link
Copy Markdown

Summary

Turbopack's CSS parser (lightningcss) fails to build projects that use CSS containing @container <name> { ... } named container queries, reporting:

Parsing CSS source code failed / Unexpected end of input on the named container query

This affects real-world CSS from libraries like nhsuk-frontend.

Root Cause

In lightningcss/src/parser.rs, the @container rule parsing has this error handling:

Err(e) => {
  if name.is_some() && input.is_exhausted() {
    AtRulePrelude::Container(name, None)
  } else {
    return Err(e);  // Fails for named queries with no condition
  }
}

When parsing @container scroll-content { ... }, input.is_exhausted() is false (because { is waiting), so the error is propagated instead of being handled gracefully.

Fix

Check self.options.error_recovery before returning the error. When error recovery is enabled (which Turbopack uses), use ContainerCondition::Unknown for unparseable conditions:

Err(e) => {
  if name.is_some() && input.is_exhausted() {
    AtRulePrelude::Container(name, None)
  } else if self.options.error_recovery {
    self.options.warn(e);
    AtRulePrelude::Container(name, Some(
      ContainerCondition::Unknown(TokenList::parse(input, &self.options, 0)?)
    ))
  } else {
    return Err(e);
  }
}

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

…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
@vercel-security-reviewer

Copy link
Copy Markdown

Security review details

Comment thread Cargo.toml
# 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" }

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Fix on Vercel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Turbopack build fails to parse valid CSS: named scroll-state container query

1 participant