Burning the last GIT commit into your telemetry/log

I enjoy knowing exactly what happens in the systems that I am actively working and that I need to maintain. One way to ease the process is to know precisely the version of the system when an error occurs. There are many ways to proceed like having a sequential number increasing, or having a version number (major, minor, path). I found that the easiest way is to leverage the GIT hash. The reason is that not only it point me into a unique place in the life of the code, but it also removes all manual incrementation that a version number has or to have to use/build something to increment a number for me.

The problem with the GIT hash is that you cannot run it locally. The reason is that every change you are doing must be committed and pushed. Hence the hash will always be at least one hash before the last. The idea is to inject the hash at build time in the continuous integration (CI) pipeline. This way, the CI is always running on the latest code (or a specific branch) and knows what is the code being compiled thus without having to save anything could inject the hash.

At the moment, I am working with Jenkins and React using the react-script-ts. I only had to change the build command to inject into a React environment variable a Git command.

"build": "REACT_APP_VERSION=$(git rev-parse --short HEAD) react-scripts-ts build",

In the code, I can get the version by using the process environment.

const applicationVersion = process.env.REACT_APP_VERSION;

The code is minimal and leverage Git system and environment variable that can be read inside React application easily. There is no mechanism to maintain, and the hash is a source of truth. When a bug occurs, it is easy to setup the development environment to the exact commit and to use the remaining of the logs to find out how the user reached the exception.

NPM locally to increase coding velocity between two projects

One advantage having a big repository is to be able to change a part quickly and see the result right away. Recently, I moved a piece of code into another library. The reason was to reuse the library on several systems. The concept of breaking apart into different cohesive library make sense, however, it comes with the price that a quick one line change can become more demanding. I found that it’s roughly 5 to 10 times slower. The reason is that a single line of change require to save the file and the code is ready to use. The same change in another repository needs to package the source code and to fetch the new package. The major problem is that everyone using the package sees the version bumping and the release may not even be ready to share. Ideally, a library is self-contained, and a group of unit tests ensures that the quality is as expected. However, in reality, it appears that a shareable version may require some checks directly on the browser.

NPM provides a solution. The solution is to share the library code locally to a local project. The beauty is that no code modification is required. The solution tells NPM to link locally instead of getting the package from the remote server.

The first step is to have your project that consumes the library and the library locally on your computer. Both projects can reside anywhere.

The second step is to go at with your command line at the location of the package.json of your library. NPM has a command called “link”. The execution of the command will specify if the creation is a success or not. If it is a success, you can use your command prompt to move to the project that consumes the library. Again, at the level of the package.json the command “npm link” must be executed. The difference is the argument that needs to specify which library to link. The name of the library is the name specified in the package.json of the library that we “npm link” at the second step. This command succeeds with an output that shows that node_modules points to the local directory.

Finally, once you are done and want to use the node_module library, you can unlink. The command to unlink is “npm unlink ” where the parameter is the parameter of the library linked. The library can also be unlinked by going back to the library and executed “npm unlink”.

As a recap:

// 1) At the library level
npm link
// 2) At the project level (consumer)
npm link my-library-name
// 3) Stop using the local version
npm unlink my-library-name
// 4) Stop sharing locally my-library-name (must move back to library level)
npm unlink

The technique works with TypeScript. The compilation of the library needs to occur since the link to the library read the package.json and will look for the “files” property which is mostly pointing to the build folder.

Before closing on the subject, make sure that both libraries are running on the same NodeJS and npm version. Each NodeJS version links to a different folder. You can confirm the location of the link by using “node -v”. Another tips is for people using “create-react-app”. In that case, you may have to close and open the development server on each change. The reason is that Webpack does not notice the change in node_modules folder and will serve you the same files of the startup.