Improve usefulness of changelog by listing changes in dependencies

[ehoogeveen-medweb]

Hi! Whenever we update our packages I like to try and provide a compact changelog in the commit description, but I've noticed that this is pretty difficult with the current changelog format for this monorepo.

Often changes are deeply nested, meaning you have to click through the changelogs of multiple packages until you find what actually changed (and then remember which package updates only contained dependency updates so you can skip them).

For an extreme example, consider the recent release of postcss-preset-env version 10.0.0. The changelog in this repo is a huge list of major version bumps of various dependencies, which themselves each have a dependency tree, but I think the actual list of changes is something like this:

• Support for Node v18+
• [css-color-parser] fix serializeP3 when gamutMapping is false
• [css-tokenizer] Improve performance
• [postcss-nesting] Make edition 2024-02 the default
• [postcss-content-alt-text] Add specific handling of content: ">" / ""; as this pattern is used in the same way as <img alt="">, i.e. to represent an item that does not need a text alternative.

It would be great if changes to dependencies could be added at the top of the changelog in a format similar to the above, with identical changes being merged ("Support for Node v18+" would be harder to deduplicate, but it's an exceptional case).

[romainmenke]

Hi @ehoogeveen-medweb,

I think that we can differentiate a changelog entry about own behavior from dependency changes.

Either through parsing or by adding some html comments to annotate the changelog entries.

I agree that it is a bit much at the moment, I also do not like how large these files become because of this.

The largest culprit is the shared dependencies.

If we change the color parser package it causes ~10 changes in individual plugins which in turn causes ~10 change log entries in postcss-preset-env.

Or even worse the tokenizer, which causes all plugins to have changes.

I think that listing links to changelogs that themselves only link to other changelogs is not that valuable.

---

Scenario:

We update the color parser package and add this to its own changelog:

fix serializeP3 when gamutMapping is false

When publishing it triggers downstream updates in:

• postcss-lab-function
• postcss-oklab-function

These would get this added to each of their changelogs:

@csstools/css-color-parser: fix serializeP3 when gamutMapping is false

When publishing it triggers downstream updates in:

• postcss-preset-env

It would get this added to its changelog:

@csstools/css-color-parser: fix serializeP3 when gamutMapping is false @csstools/css-color-parser: fix serializeP3 when gamutMapping is false

Which we can dedupe into a single entry.

@csstools/css-color-parser: fix serializeP3 when gamutMapping is false

---

Scenario:

We update the color parser package and add this to its own changelog:

fix serializeP3 when gamutMapping is false

When publishing it triggers downstream updates in:

• postcss-lab-function
• postcss-oklab-function

These would get this added to each of their changelogs:

@csstools/css-color-parser: fix serializeP3 when gamutMapping is false

We also update postcss-lab-function and add this to its own changelog:

fix something important

When publishing it triggers downstream updates in:

• postcss-preset-env

It would get this added to its changelog:

@csstools/css-color-parser: fix serializeP3 when gamutMapping is false @csstools/css-color-parser: fix serializeP3 when gamutMapping is false postcss-lab-function: fix something important

Which we can dedupe into a two entries

@csstools/css-color-parser: fix serializeP3 when gamutMapping is false postcss-lab-function: fix something important