[Bug]: merge-longhand is unsafe with css variables

[yepitschunked]

Describe the bug

It's unsafe to merge something like

padding-top: --var(foo);
padding-bottom: --var(bar);
padding-left: --var(baz);
padding-right: --var(quux);

since the result could differ from the original if any of the variables are undefined or have a blank value. For example, if only foo is defined, you would wind up with padding: <value of foo>, i.e foo padding in all directions, instead of just padding-top.

Expected behaviour

Rules should not be merged

Steps to reproduce

Run postcss-merge-longhand with

padding-top: --var(foo);
padding-bottom: --var(bar);
padding-left: --var(baz);
padding-right: --var(quux);

as input

Version

5.1.13

Preset

(no preset)

Environment

irrelevant

Package details

irrelevant

Additional context

No response

[alexander-akait]

Theoretically you are right, but I don't see such a problem in real world, no one use :root { --foo: 10px 10px; padding-top: var(--foo); }

Maybe you can provide example?

[yepitschunked]

It's more that

.foo {
  padding-top: var(--padding-top);
  padding-bottom: var(--padding-bottom);
  padding-left: var(--padding-left);
  padding-right: var(--padding-right);
}

cannot be safely merged into

.foo {
  padding: var(--padding-top) var(--padding-right) var(--padding-bottom) var(--padding-left);
}

This happens currently because the library only checks whether all values to be merged are css variables:

cssnano/packages/postcss-merge-longhand/src/lib/canMerge.js

Lines 26 to 32 in 65674d4

	if (
	includeCustomProps &&
	props.some(isCustomProp) &&
	!props.every(isCustomProp)
	) {
	return false;
	}

But I think it should additionally check that they're all referring to the same css variable.