NPM locally to increase coding velocity between two projects
Posted on: 2018-04-03
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.