ci: adjust release page generation

[michaelfaith]

PR Checklist

• Steps in CONTRIBUTING.md were taken

Overview

This change is a POC to address JoshuaKGoldberg/create-typescript-app#1913. Since it's not something we can really test locally, I figured we test it out here, and then, if successful, I can make the updates upstream.

Here we've changed the release-it config from json to js, which allows us to create a custom function for github.releaseNotes. Using the context provided by release-it, we can filter by groups that we want to keep, and organize them into the same groups that we're organizing for the CHANGELOG (via conventional-changelog). 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.

[github-actions]

PR Compliance Checks

Thank you for your Pull Request! We have run several checks on this pull request in order to make sure it's suitable for merging into this project. The results are listed in the following section.

Issue Reference

In order to be considered for merging, the pull request description must refer to a specific issue number. This is described in our Contributing Guide. We are closing this pull request for now but you can update the pull request description and reopen the pull request.
The check is looking for a phrase similar to: "Fixes #XYZ" or "Resolves #XYZ" where XYZ is the issue number that this PR is meant to address.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.86%. Comparing base (668eaee) to head (42d71da).
Report is 11 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #772   +/-   ##
=======================================
  Coverage   97.86%   97.86%           
=======================================
  Files          19       19           
  Lines        1172     1172           
  Branches      140      140           
=======================================
  Hits         1147     1147           
  Misses         25       25           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JoshuaKGoldberg]

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. 🚀

[JoshuaKGoldberg]

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

[michaelfaith]

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)

[JoshuaKGoldberg]

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?

[JoshuaKGoldberg]

I like how the output should function, but not having so much JS logic for the release-it config. Commented inline - I think this is a place where we should contribute upstream rather than DIY.

[JoshuaKGoldberg]

😬 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?

[michaelfaith]

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?

[JoshuaKGoldberg]

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.

[JoshuaKGoldberg]

Since it's not something we can really test locally,

Btw I'd recommend making a dummy package and having that go through the same motions as a regular one. Example: I made https://github.com/JoshuaKGoldberg/cta-publish-testing -> https://www.npmjs.com/package/cta-publish-testing to test out the release flow.