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:

React Native Layout Management With Yoga 3.0

React Native layout management with Yoga 3.0

Explore layout management in your React Native apps with the latest release of React Native v0.74 and Yoga 3.0.

Andrew Baisden
May 30, 2024 ⋅ 8 min read
A Guide To Javascript Parser Generators

A guide to JavaScript parser generators

Explore three JavaScript parser generator libraries and the benefits of creating custom parsers for specific project needs.

Yashodhan Joshi
May 30, 2024 ⋅ 16 min read
Using Rust And Axum To Build A Jwt Authentication Api

Using Rust and Axum to build a JWT authentication API

Learn to build a basic JWT authentication system with Rust and Axum, including setting up the routes, handlers, and the middleware system.

Eze Sunday
May 29, 2024 ⋅ 9 min read
Building A Customizable Dashboard With Dashy

Building a customizable dashboard with Dashy

Dashy helps us create beautiful, customizable, modern dashboard pages with web service links and widgets.

Shalitha Suranga
May 29, 2024 ⋅ 10 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