Hello, everyone! I am Jisu, UI Engineer at Slid😊 I would like to share how I develop npm packages for design components, which issues I face, and how I handle them in this post.
Usage of npm package at Slid
Why Slid start to use the npm package🤯
At Slid, we develop each front-end separately for web, extension, and desktop. Since our service is getting bigger, we found out that some UI components are implemented repeatedly. In addition, Front-end Hackers spent more time on UI detail rather than developing the feature itself and it affected the sprint schedule. Therefore we decided to separate the UI component from front-end development and manage it independently.
IPS, Design Component System of Slid🎨
Hence, Slid started to build our design systems and design components with npm package such as Bootstrap and Material UI. In detail, UI Engineers and Designers at Slid continuously implement design systems and design components on the npm package called IPS(Interactive Product System). Then UI Engineers and Front-end Hackers use the components from IPS to implement the UI of the service.
What was the problem when developing the npm package?
Every application has a different setup😕
As I mentioned, Slid divides the workspace for IPS and the web. In the IPS repository, we develop design components and we develop the front-end for the service in the web repository. In other words, the IPS is the my-package in the above picture and the web is my-app in the picture. And the web can be represented with the application.
The ultimate reason for developing IPS is to apply unified design components more easily when hackers implement variable applications. In other words, it doesn’t mean anything if IPS doesn’t work on different applications. Therefore checking it on the application is essential. For that, I need to publish the package and install it on the application. And I expect each design component will show up as same as I implement. But, it wasn’t the same as I expected.🤦♀️
Some components look different, some of them are located in the wrong place because of several reasons such as different CSS initialization levels. To make it work, I should modify the component, publish it, install it on the application and check the detail again and again. After I repeat this process several times, I realized this is not the right way to build the package.🤔
The reason I decided to get out of the infinite publishing process
There are two reasons why I decided to find a way to stop publishing the package again and again. First, it causes unnecessary communication with coworkers continually. Because I should share my progress to publish IPS with the coworker who implements different components on the IPS. I felt this process disturbs us from working smoothly.
The other reason was version management. At this moment, I did the publishing process on the feature branch without merging the work on the develop branch or master branch. Because I was in hurry to check the result of each component on the application. At that point, we couldn’t track which components included in which version, and we are failed to manage the version for the npm package. Therefore I thought we should figure out a way to check the recent status of the package without publishing it.
How can we test the recently modified package on the application before publishing?
Test the recently modified package without publishing📦
After I explored several references, I choose to use npm pack to make it work. With this solution, I expect I can apply the recently modified package on the application. And I used it during the last sprint to check its utility.
How it works👩💻
Pack the package
The base process is similar to the publishing process. Updating version is dropped, and you should execute npm pack instead of npm publish
~/workspace/package-name $ npm packAfter you type npm pack, you can find the .tgz file inside of the root directory. As you can check on the official document for npm pack, the .tgz file is formed like <package-name>-<version>.tgz, and the version is marked as the latest version.
Install the .tgz file
It is simple to use the file. Move the file wherever you want and install it on the application you want to apply the package. For example, if you locate the file inside of the workspace folder on the desktop and use it on the repository named web, you can follow the below statement.
~/workspace/web $ npm install ~/desktop/workspace/<package-name>-<version>.tgzWith this process, not only those who implement the package, but also the other developer who should use the package can check the recent version of the package easily.
After you install the file, you can use the components inside of the package as same as you use the other npm packages!
Delete the .tgz file
When you finish improving the package using the .tgz file, now you are on the publish step. At this point, you should delete the .tgz file before you start publishing. After publish, you should replace the .tgz file route for the package with the actual updated version on the applications. You can use the below statement to update the package with the latest version.
~/workspace/web $ npm install package-name@latestThoughts on using npm pack
I felt that I speed up the workflow using npm pack since it removes unnecessary processes. And in a version management perspective, it looks the right way because I modified the package and checked it on applications without considering the version.
But at some point, I should publish the package to apply the components on the deployable application even if some are not completed. For example, if Front-end Hackers are done with implementing a new feature on a feature branch and ready to merge it to develop, I should publish the package even if the IPS works from coworkers are not completed. Otherwise, IPS will not work on the actual service! Therefore sometimes unfinished components are published together.
Care in advance!
Through this experience, I realized that implementing well from the first step is really important. I thought it would be better if I consider the details early on and minimize the modifying process. Even if npm pack process reduces the energy and time, it is still additional work. So I thought I should take more care in developing design components that are stable in every application.
Thanks for reading this post!😊
Reference
https://medium.com/@vcarl/problems-with-npm-link-and-an-alternative-4dbdd3e66811
