css border shorthand incorrectly minified in production

[stefanprobst]

Verify canary release

• I verified that the issue exists in Next.js canary release

Provide environment information

Operating System:
Platform: linux
Arch: x64
Version: #33~20.04.1-Ubuntu SMP Mon Feb 7 14:25:10 UTC 2022
Binaries:
Node: 16.14.0
npm: 8.3.1
Yarn: 1.22.17
pnpm: 6.30.0
Relevant packages:
next: 12.1.1-canary.9
react: 17.0.2
react-dom: 17.0.2

What browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

Describe the Bug

currently, the css minifier (i think this is the compiled-in cssnano-simple) produces invalid css from the following:

h1 {
  --border-width: 8px 2px;

  border-width: var(--border-width);
  border-style: solid;
  border-color: hotpink;
}

results in:

h1{--border-width:8px 2px;border:var(--border-width) solid hotpink}

which is invalid.

note that this is currently also handled incorrectly in upstream cssnano with the default preset, but works correctly with the "lite" preset. cf. cssnano/cssnano#1354

Expected Behavior

don't collapse border properties into shorthand when custom properties are encountered

To Reproduce

• checkout https://github.com/stefanprobst/next-issue-css-shorthand and compare the results of yarn dev vs yarn build && yarn start

[wwwdepot]

It's an optimization enabled by cssnano, See mergeLonghand https://cssnano.co/docs/what-are-optimisations/.

[balazsorban44]

Next.js is using a custom variant of the cssnano-preset-default preset, source here: https://github.com/Timer/cssnano-preset-simple

Adding mergeLonghand: false to that and re-compile it for Next.js here:

next.js/packages/next/build/webpack/plugins/css-minimizer-plugin.ts

Line 47 in f14f628

return postcss([cssnanoSimple({}, postcss)])

might fix the issue, but it looks like cssnano acknowledges this as a bug and we should probably wait for a proper fix on their side: cssnano/cssnano#675 🤔 (admittedly though, that issue has been opened for 3 years now).

Another downside would be that it could affect most current CSS outputs negatively, so the workaround has a cost.

[stefanprobst]

there is now a fix for this issue in upstream cssnano v5.1.3

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.