support an option to keep invalid css in the output

[hardfist]

This is a follow up issue of https://github.com/parcel-bundler/lightningcss/issues/209 and thank you support errorRecovery to make migration from postcss to lightningcss much easier. But there's still a pain point that user might still want to keep the invalid css to leave it processed by other tools, so it may make sense to support an option to keep the invalid css in the output, we met some problem when use lightningcss in rspack related to this

• https://github.com/web-infra-dev/rspack/issues/8695#issuecomment-2540704499
• https://github.com/web-infra-dev/rspack/issues/10056

also seems related issue in turbopack

• https://github.com/parcel-bundler/lightningcss/pull/954

Discussed similar problem with webpack and esbuild author about how to deal with invalid css in https://github.com/evanw/esbuild/issues/1946#issuecomment-1017203765 and it seems keep invalid css may make sense.

Again Thanks for your great work!

[devongovett]

keep the invalid css to leave it processed by other tools

Can you make pre-processors run before lightningcss so that the input to lightningcss is valid?

Skipping over invalid rules is what browsers do as well. Preserving all of these invalid tokens would require significant changes to the AST format to basically every rule to be able to store tokens in arbitrary positions. There may be more specific cases like #209 that can be handled though. In that case it's type checking that fails, not parsing.

I think there needs to be some degree of following the CSS spec though, or it gets very difficult to deal with. The :deep(.foo)-bar syntax is a case that does not match the selectors grammar (an identifier (-bar) cannot immediately follow a functional pseudo class (:deep(.foo)). Another one is tailwind's --color-*: initial syntax which doesn't match the declaration grammar (this tokenizes as an ident --color- followed by a delim *). Usually these can be processed by another tool to convert them into valid CSS before passing their output to lightningcss though.

[hardfist]

Can you make pre-processors run before lightningcss so that the input to lightningcss is valid?

actually it's decided by users, they can choose run other tools after lightningcss-loader, so it's not controlled by us and it's also a common practice from webpack ecosystem and when user migrate from postcss to lightningcss(this is one of main usage), this behavior may surprise users.

I do agree that error recovery for any syntax is both challenging for css parser & js parser 😭

but if you agree to support this, maybe we can try work on it

[devongovett]

actually it's decided by users

Could it be considered a configuration error though?

That's like if the JS parser also had to accept coffeescript as input.

[hardfist]

Could it be considered a configuration error though?

I'm not sure, maybe it's a bad practice but we saw lots of users met this problem, especially some framework(like vue) has it's specially syntax for css https://github.com/vuejs/rfcs/blob/master/active-rfcs/0023-scoped-styles-changes.md#basic-example

<style scoped>
/* deep selectors */
::v-deep(.foo) {}
/* shorthand */
:deep(.foo) {}

/* targeting slot content */
::v-slotted(.foo) {}
/* shorthand */
:slotted(.foo) {}

/* one-off global rule */
::v-global(.foo) {}
/* shorthand */
:global(.foo) {}
</style>

That's like if the JS parser also had to accept coffeescript as input.

I think yes if the JS parser fully supports recovery, coffescript biome biome will treat invalid syntax as bogus as it is, I'm not sure whether lightningcss can do similar things

[devongovett]

I think all of those examples already work see here, just with warnings. Do you have a list of cases that produce broken output/errors?

[Jimbolino]

[lightningcss minify] 'v-deep' is not recognized as a valid pseudo-element. Did you mean ':v-deep' (pseudo-class) or is this a typo?

would it be possible to suppress this warning message using a config setting?