fix(changelog): use effect, because hidden does nothing - #35
Conversation
`{ type: "style", hidden: true }` never hid anything.
conventional-changelog-conventionalcommits 10 reads `effect` and no other
field, so `style: format the repo with oxfmt` shipped in the v1.0.12 release
body. It rendered as a bare bullet above Bug Fixes with no section heading,
because the entry carried `hidden` instead of `section` and the writer had no
group to file it under. `test` was marked the same way.
The list moves to `effect` throughout and follows the same rule as the other
repos: whether a type can change what npm hands a consumer. `files` is
["build", "app.plugin.js"], so `build`, `refactor`, `chore` and `docs`
render, and `ci`, `style` and `test` do not. `ci` had its own section until
now. Everything that renders without being able to change the version is
`effect: "changelog"`, so a release of nothing but `build:` commits is still
a patch.
`commitFilter` is gone too, for the same reason: the plugin destructures
`preset`, `context`, `gitRawCommitsOpts`, `parserOpts`, `writerOpts` and
`whatBump`, and the key appears nowhere in its source. Nothing was lost by it
doing nothing. What actually keeps the `chore(release)` bump commits out of
the notes is the workflow merging the bump PR instead of squashing it, since
conventional-changelog skips merge commits. Both v1.0.12's and v1.0.13's have
two parents. The workflow comment claimed the filter did it; it now says what
does.
The config moves to `.release-it.mjs` so the type list can live in
tools/changelog-preset.mjs and be shared with tools/changelog-check.mjs,
which renders a synthetic history of every type and asserts each one renders
or stays out per a policy written down longhand. It also measures the bump,
and re-renders through a sabotaged list to prove the assertions can fail.
Wired into CI.
Now that the types carry `effect`, only the `bump` ones can raise a version, so a cycle of nothing but docs/chore/build/refactor recommends nothing at all. release-it prints "No new version to release", exits 0 and leaves the tree alone. The workflow read that as success and carried on: it pushed a branch at master's head, failed to open a PR against it because there were no commits between the two, and reported that npm and the tag were already out when neither was. Gate the step on the version actually moving and say so in the log instead. The preset comment claimed a build-only release was "still a patch". It isn't, and the check next to it already asserted otherwise.
|
Reviewed, and merging. The Same 9-commit synthetic history through both type lists, with the bump each type recommends on its own:
That column also contradicts a line in the new preset comment, "a release of nothing but When release-it recommends nothing it prints "No new version to release" and exits 0. Checked the ESM move too, since a config release-it can't find would fail silently and publish with defaults.
|
1 participant
style: format the repo with oxfmtis in the v1.0.12 release body, over a{ type: "style", hidden: true }entry that claimed to suppress it. conventional-changelog-conventionalcommits 10 readseffectand no other field, sohiddendoes nothing.testwas marked the same way.It rendered as a bare bullet above Bug Fixes with no section heading, because the entry carried
hiddeninstead ofsectionand the writer had no group to file it under.Reproduced by replaying the plugin's own
getChangelogStream()over the same range with the repo's real config. The output matches the shipped body except for one line, thechore(release)bump commit that didn't exist yet when the real changelog ran.Types
effectthroughout, split by whether a type can change what npm hands a consumer.filesis["build", "app.plugin.js"]:build/.github/isn't infilesbuild/ships, and oxfmt oversrc/cannot move what tsc emitsfilescihad a section of its own until now. Everything that renders without being able to change the version iseffect: "changelog", so a release of nothing butbuild:commits is still a patch.commitFilter
Also removed, for the same reason. The plugin destructures
preset,context,gitRawCommitsOpts,parserOpts,writerOptsandwhatBump;commitFilterappears nowhere in its source.What keeps the
chore(release)bump commits out of the notes isrelease.ymlmerging the bump PR instead of squashing it, since conventional-changelog skips merge commits. Both v1.0.12's and v1.0.13's bump commits have two parents. The workflow comment credited the filter, so it now names the--mergeflag as the thing doing that job.Check
tools/changelog-check.mjsbuilds a throwaway repo with 12 commits, one per type, 3 of them breaking, renders it through the real preset and asserts each type renders or stays out per a policy written down longhand in the check itself. Deriving the policy from the preset would make every assertion a tautology: hide a section and the check quietly redefines what it expected.It measures the bump too, and re-renders through a sabotaged type list, failing if that run passes.
ciis hidden and theci!:commit's breaking note still has to surface.The config moves to
.release-it.mjsso the type list can live intools/changelog-preset.mjsand be shared. conventional-changelog-conventionalcommits is ESM-only, so a CJS config could only reach it through a dynamic import. Wired into CI, chained ontonpm pack --dry-runsince the shared workflow has a singleextra-command.No release
Release is
workflow_dispatchonly, and nothing here warrants one. Rehearsed on a throwaway clone with publish, push and the GitHub release off: 1.0.13 -> 1.0.14 with Bug Fixes and Documentation sections, zero lines removed from CHANGELOG.md.