`stylelint --fix` drops a trailing interpolation on its own line in a multi-line CSS value

[aki05162525]

Environment

• Linaria version: @linaria/postcss-linaria 6.3.0 (also reproduces on 8.1.1, the latest)
• Stylelint version: 17.14.1
• PostCSS version: 8.5.23
• Bundler (+ version): N/A (reproduces via stylelint CLI directly)
• Node.js version: 24.16.0
• OS: macOS

Description

When a CSS value spans multiple lines and the last argument is an interpolated expression (${...}) alone on its own line, stylelint --fix (with customSyntax: '@linaria/postcss-linaria') silently drops it — no error, the line just becomes empty.

This reproduces with zero rules configured, so the corruption occurs during the @linaria/postcss-linaria parse/stringify round trip invoked by --fix, rather than in a specific Stylelint rule fixer.

Likely cause: createPlaceholder classifies an interpolation on an expression-only line as a rule set because isRuleSet finds no colon, opening brace, or comma on that line. It therefore emits a comment placeholder (/* pcss_lin:1 */) instead of a value placeholder (pcss_lin1).

PostCSS omits that comment from Declaration#value, and locationCorrectionWalker stores the resulting comment-free value in raws.linariaValue. By the time the custom stringifier runs, the placeholder is no longer present and the interpolation cannot be restored.

Reproducible Demo

.stylelintrc.mjs:

export default {
    customSyntax: '@linaria/postcss-linaria',
    rules: {},
};

sample.style.ts:

import { css } from '@linaria/core';

const color = 'gray';
const transparentColor = 'transparent';

export const style = css`
    .foo {
        background: linear-gradient(
            0deg,
            ${color} 20%,
            ${transparentColor}
        )
    }
`;

stylelint --config .stylelintrc.mjs --fix sample.style.ts

${transparentColor} is removed, leaving:

background: linear-gradient(
    0deg,
    ${color} 20%,

)

[Anber]

Thanks for this. The report is unusually good: the repro runs exactly as given, and your read of the cause holds at every step, down to isRuleSet picking the comment placeholder and locationCorrectionWalker then storing the comment-free value.

One refinement. The trigger is not multi-line values in general, it is an unclosed parenthesis. Without one, PostCSS ends the declaration and parses the placeholder as its own comment node, which the stringifier's comment() handler restores correctly. Inside linear-gradient( the declaration cannot end, so the comment stays inside the value, and that is where it was lost. Nested calls like calc(… max(…)) fail the same way.

The fix reads the re-indented value from raws.value.raw, which keeps the comment, and teaches the placeholder substitution to recognise the comment form.

Writing tests for it turned up three more problems in the same code, all with the same shape, so #1495 fixes them together:

• multi-line at-rule params were corrupted rather than dropped: @media screen and ${query} came out as @media screen and .pcss-lin0
• an interpolation on the line after the at-rule name lands in the afterName raw and was emitted verbatim
• a newline inside afterName never had its base indentation restored, so a wrapped at-rule prelude lost its leading whitespace on any fix, even in templates containing no interpolations at all

One thing worth spelling out, since it makes this worse than it looks: the damage is not limited to runs where nothing else changes. Any rule that does fix something takes the interpolation with it, so a --fix you ran to tidy up formatting can quietly delete code.

The fix is in #1495 and will go out with the next release.

[aki05162525]

That was fast. The unclosed-parenthesis explanation makes total sense. Thanks!