vernak2539 / astro-rehype-relative-markdown-links

Rehype Plugin for Astro that allows for usage of relative links between markdown files
https://www.npmjs.com/package/astro-rehype-relative-markdown-links
12 stars 4 forks source link

Automatically update changelog for new versions #41

Closed vernak2539 closed 6 months ago

vernak2539 commented 6 months ago

Use github-changelog-generator to automagically update the changelog after a version has been published to npm...

techfg commented 6 months ago

@vernak2539 - Good to see this getting automated, but a couple of downsides to this approach in/around the CHANGELOG itself:

  1. It won't be in the tagged version commit since it's generated after so when viewing the Release vX commit itself or the code from the version tag, it won't be in there/have the old one
  2. It won't be included in the npm publish so the CHANGELOG on npm will show the prior version than the one being viewed

Not the end of the world on either front but not ideal either 😦 Up to you if its something you want to address or just leave as is.

Also, on a related note, might be helpful to add the --frozen-lockfile to the yarn command.

vernak2539 commented 6 months ago

Yeah, unfortunately there's not a great approach IMO.

It won't be in the tagged version commit since it's generated after so when viewing the Release vX commit itself or the code from the version tag, it won't be in there/have the old one

Feel like people can just look at the main branch for the changelog ha. I'd need to require requiring something like semantic commits and automatic version bumps to do this... don't think I'm there yet

It won't be included in the npm publish so the CHANGELOG on npm will show the prior version than the one being viewed

Yeah, maybe I'll de-dryify the code to generate the changelog before the npm publish...

thatnks for the thoughts!

techfg commented 6 months ago

Since you'll likely be the only one generating releases (at least for now) and you're tagging the version commit manually (at least I think so), one option would be to just run it manually then commit with the tag (guessing this was what you were doing before anyway). Another option would be to setup a github workflow that automates everything in order and kick that off manually so it all runs server side (this way official contributors could do it as well as some point).

Either way, not worth overengineering at this stage that's for sure :)

techfg commented 6 months ago

@vernak2539 - Saw the recent update to the workflow, nice! One other idea just occurred to me since it looks like you are likely tagging the versions manually. You could use npm version command with a version hook that would run the change log generator just prior to commit. Could do this manually (console or npm script) or run it all in a github workflow (different flow for patch/minor/major or an argument if workflows allow arguments). Ok, enough deployment engineering for one day :) lol