2021-07-30
1710
#node
Indermohan Singh
61102
Jul 30, 2021 ⋅ 6 min read

Automatically generate and release a changelog using Node.js

Indermohan Singh JavaScript developer interested in Angular, RxJS, and Ionic framework.

Recent posts:

how to design apps with Apple Intelligence in mind

How to design apps with Apple Intelligence in mind

Apple Intelligence is here. What does it mean for frontend dev and UX? Explore the core features of the update, do’s and don’ts for designing with Apple Intelligence in mind, and reflect on the future of AI design.

Murat Yüksel
Jun 24, 2025 ⋅ 10 min read
How To Optimize Your Next.js App With After()

How to optimize your Next.js app with after()

Next.js’ after() is a new API that lets you run logic after your route has finished rendering, without blocking the client.

Temitope Oyedele
Jun 24, 2025 ⋅ 11 min read
JavaScript Loops Explained, And Best Practices

JavaScript loops explained, and best practices

JavaScript loops like for, for...of, and for...in are constructs that help run a piece of code multiple times.

Rahul Padalkar
Jun 23, 2025 ⋅ 8 min read
8 Reasons Your Next.js App Is Slow — And How To Fix Them

8 reasons your Next.js app is slow — and how to fix them

You don’t need to guess what’s wrong with your Next.js app. I’ve mapped out the 8 biggest performance traps and the fixes that actually work.

Chizaram Ken
Jun 20, 2025 ⋅ 16 min read
View all posts

4 Replies to "Automatically generate and release a changelog using Node.js"

  1. Often our team will make commits on each feature or developer branch, sometimes these may be work in progress changes. Such as committing work at the end of the day even though it isn’t feature complete or other various reasons. How does this workflow fit in with partially feature complete commits? It doesn’t make sense to follow this for every commit when all that matters to us is the squashed commit for release. Can this workflow only be applied to named branches? Would love to see and edit or follow-up on this related area.

    1. Thanks Ash. That’s a good question.

      1. You can always use a commit message which has the conventional commit structure but doesn’t have details. E.g: “type: WIP”. Here type can be feat, fix, chore and so on.

      2. Before you merge the feature branch then you clean the commit messages and merge.
      3. From there on, it’s like mentioned in the article.

      I hope it helps. I’d be interested in writing a follow up article.

      Thanks.

Leave a Reply