Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ci: adjust release page generation #772

Closed
wants to merge 2 commits into from
Closed

ci: adjust release page generation #772

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
62f5813
ci: rename release-it config to js
michaelfaith Jan 25, 2025
42d71da
ci: adjust release page generation
michaelfaith Jan 25, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/actions/prepare/action.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ runs:
- uses: actions/setup-node@v4
with:
cache: pnpm
node-version: "18"
node-version: "22"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the prepare action to use node 22, which will allows to use the Object.groupBy api (introduced in v21). Since 22 is now LTS, I though that was probably ok? But if you'd rather leave it on node 18, I'm happy to refactor that.

For context, the reason I'd kept it on 18 even after 20 went LTS is to make sure scripts that actually run the code don't crash on older Node.js versions. Specifically Node.js APIs aren't checked by TypeScript the way globals or syntax are. But CTA repos now include lint rules like n/no-unsupported-features/es-builtins. So I think this is fine to switch for faster Node.js performance + more built-ins. 🚀

- run: pnpm install --frozen-lockfile
shell: bash
using: composite
60 changes: 60 additions & 0 deletions .release-it.js
View file
Open in desktop
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😬 This is a lot to add for one aspect of configuration. I don't like the idea of the template including so much custom code. Part of the goal of CTA is to show off making great web dev repos without manual configuring. This is kind of the opposite.

But, the feature here of having a changelog with grouped types seems very universally applicable and good to me. So much so that I think it arguably could be a first-class feature of the plugin. I.e. I think an equivalent "types" config should really be present for github. What do you think about filing a feature request over on release-it for either:

  • Porting the types array option to github
  • Adding a plugin like @release-it/conventional-releases for GitHub release, similar to @release-it/conventional-changelog?

Copy link
Collaborator Author

@michaelfaith michaelfaith Jan 27, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think that it would make sense to incorporate into release-it's core functionality. The Conventional Changelog project (which is what the conventional-changelog release it plugin uses), does have a GitHub releaser package: https://github.com/conventional-changelog/releaser-tools/tree/master/packages/conventional-github-releaser
example output: https://github.com/conventional-changelog/conventional-changelog/releases/tag/standard-changelog-v6.0.0

I guess, would you want to wait for that to be implemented upstream, or go with something like this for now, until it's available?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'd prefer to wait for upstream, yeah. As much as the awkwardly chore-heavy changelogs irk me, I've been bit by people getting the 'ick' from CTA having too much configuration in it.

Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
module.exports = {
git: {
commitMessage: "chore: release v${version}",
requireCommits: true,
},
github: {
release: true,
releaseName: "v${version}",
releaseNotes(context) {
const groupTitles = {
feat: "Features",
fix: "Bug Fixes",
perf: "Performance Improvements",
};
const commits = context.changelog.split("\n").slice(1);
const groups = Object.groupBy(commits, (commit) => {
// If it matches one of the types we care to show, then add the
// commit to that group.
for (const type in groupTitles) {
const regex = new RegExp(`^\s*[-*]?\s*${type}[(:]`);
if (regex.test(commit)) {
return type;
}
}

// If it didn't match any of the important groups, then add it to other
return "other";
});

// Use the data we've collected to build the release notes.
const releaseNotes = [];
for (const type in groupTitles) {
if (groups[type]) {
releaseNotes.push(`### ${groupTitles[type]}`);
releaseNotes.push(...groups[type]);
}
}
return releaseNotes.join("\n");
},
},
npm: { publishArgs: ["--access public", "--provenance"] },
plugins: {
"@release-it/conventional-changelog": {
infile: "CHANGELOG.md",
preset: "angular",
types: [
{ section: "Features", type: "feat" },
{ section: "Bug Fixes", type: "fix" },
{ section: "Performance Improvements", type: "perf" },
{ hidden: true, type: "build" },
{ hidden: true, type: "chore" },
{ hidden: true, type: "ci" },
{ hidden: true, type: "docs" },
{ hidden: true, type: "refactor" },
{ hidden: true, type: "style" },
{ hidden: true, type: "test" },
],
},
},
};
30 changes: 0 additions & 30 deletions .release-it.json
View file
Open in desktop

This file was deleted.

1 change: 1 addition & 0 deletions eslint.config.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,7 @@ module.exports = tseslint.config(
"lib",
"node_modules",
"pnpm-lock.yaml",
".release-it.js",
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is to exist, I'd rather it be linted with allowDefaultProject.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with that, but then I think we should turn some of these rules off for js files (or at least this js file)

screenshot of eslint ts violations

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or add proper types? I put a /** @param {{ changelog: string }} context */ atop the releaseNotes, change the groupTitles loop to a for (const [type, typeTitle] of Object.entries(groupTitles), and most were fixed.

I suspect there's a feature request to be filed upstream in release-it to expose a type we can slap on the whole module.exports. I think @type {import("release-it").Config} would be it, but the releaseNotes function doesn't mention the context param:

https://github.com/release-it/release-it/blob/897fc3133b9de4107aef7ebb6a120fece174a773/types/config.d.ts#L109

WDYT?

],
},
{ linterOptions: { reportUnusedDisableDirectives: "error" } },
Expand Down
Loading