Quick Answer
Vite changes the order in which it assembles Rolldown output settings so that its computed comments configuration is not overwritten by a later object spread.
In Plain English
JavaScript objects are often built by combining defaults with user options. When two entries use the same key, the later entry wins. That rule is convenient, but it can erase a carefully constructed combination of defaults and overrides if the order is wrong.
Code Evidence
In packages/vite/src/node/build.ts, the comments expression moves below the spread of output. Boolean comment settings remain booleans. Object settings are combined with defaults for annotations, JSDoc, and legal comments. The code also treats ES library output specially when deciding whether to keep annotations used by tree shaking.
The overwrite that hides a computed value
Object spread follows an order that can be easy to miss during review. If an object computes comments and then spreads an output object that also contains comments, the spread replaces the earlier value. It does not recursively combine the nested categories. Moving the computed comments entry after the spread lets the explicit expression determine the final value. The relevant change is therefore precedence within one assembled options object, even though the underlying expression already existed.
This is particularly significant for a partial object setting. A caller can specify one comment category while relying on Vite to supply defaults for others. The expression combines those categories, but that work has no effect if a later spread replaces the combined object with the original partial input. Placing the expression last makes its merging behavior effective. For a boolean input, the expression keeps the explicit boolean, so the distinction between an all-or-nothing choice and a category-level choice remains visible.
Why library authors should inspect the artifact
A library package can pass through more than one build. Its author produces the distributable, and a consuming application may bundle that output again. Some annotations in the library's output can be useful to the later bundler's tree-shaking decisions. The reviewed code treats ES library output specially when determining annotation retention. That connection explains why a comments option is more than a cosmetic formatting preference, while leaving the actual effect dependent on the complete build pipeline.
Legal comments and JSDoc belong to different categories and may serve different needs. A project should decide which emitted information it needs rather than interpreting the broad word comments as a single requirement. The diff does not promise that all categories survive every format or minification combination. Nor does it demonstrate a package-size improvement. Its narrower contribution is ensuring that the intended category calculation is not discarded by object construction order.
A practical build comparison
For a meaningful local check, use a tiny library fixture containing a recognizable annotation, a JSDoc block, and a legal-comment example. Build it with the same output format and minification settings used for publication. Compare a boolean comments setting with a partial object setting, and inspect the emitted files rather than only the resolved configuration. This is a suggested validation method, not a report of builds executed for this article.
Keep the source and toolchain inputs constant when comparing Vite versions. If the library produces several formats, check each relevant artifact because the code's ES-library condition means one output is not necessarily representative of another. If the team depends on downstream tree shaking, add a small consuming application that imports a limited part of the package and examine its result. That additional check addresses the consumer's behavior, which cannot be inferred from the presence of one comment alone.
Reviewers can also apply the same reasoning to nearby configuration code without launching an unrelated refactor. Whenever defaults and user options share a key, identify the intended winner and inspect the complete construction order. A nested merge expression deserves special attention because a later shallow spread can silently erase it. In this patch, relocating the existing expression is sufficient to make the precedence explicit and preserve the calculation already chosen by the maintainers.
Why It Matters
For a library maintainer, output comments can carry information beyond explanations for readers. Annotations may help a downstream bundler decide what can be removed. Our interpretation is that a reliable merge makes build configuration easier to reason about. It does not mean every comment is retained or that every library becomes smaller.
An Open Question
Which comment categories does your published artifact actually require? The answer depends on the output format and minification settings. Inspecting the final package remains more informative than assuming an option name guarantees a particular emitted file.
Scope and Limitations
The diff relocates an existing expression; it does not introduce a new comment syntax. We reviewed the code but did not build or audit a published library.