Following on from the previous part of this series which detailed how to use pre-commit to configure hooks to validate branch naming, this post will do the same thing using Husky in an NPM based project.
In many organisations there are conventions on how Git branches should be named. As with all aspects of code quality, it is better to be able to identify these issues before they are pushed into version control.
There is not a hook that we can specifically use at the point that a branch is created, so the best we can do is ensure that commits are not made to the newly created branch.
This is just a quick post to announce that a new version of the generate_service.sh script is now available.
Instead of putting the source for this into this post, I’ve now committed it to a Github repository here: generate_service.sh. This version adds support for generating additional service files for accessories defined under a platform in Homebridge.
I have been testing this out with a Samsung Tizen based TV, but this has exposed another issue with Wake-on-Lan packets not being able to be routed from a Docker network without using host mode. I’m still investigating options to solve this, which will be another post (or defeat, time will tell).
Git hooks are a fantastic first step for identifying issues before code is pushed to a repository. However, the configuration files which control these client-side hooks cannot be committed to the repository and need to be configured on each client once the repository has been checked out.
In the NPM world, Husky is a tool which is used to maintain commit hooks through the package.json file, and integrates with the NPM build lifecycle to keep the contents of the local “.git/hooks” folder up to date. With this, I have been using commitlint for ensuring commit messages conform to a standard format, as well as ensuring code has had linting checks ran against it.
I had a look for a similar solution for Maven, but could not immediately find one. I wanted to find a solution that could be integrated with the Maven lifecycle, like Husky does for NPM.
Throughout this series of blog posts I am looking at how to manage third party dependencies in the software development lifecycle. Before we get into how to automate the process of checking library licenses and checking if they are up to date, it is worth looking at how to do this yourself.
In this blog post I will look at the tools available for scanning an Angular application, which would also work for any type of project using NPM.