Different approaches to testing your own packages locally: npm yalc

This is part of a series of articles:

1. Linking local files
2. npm link
3. npm yalc
4. Verdaccio
5. Relative deps

In this article we'll be looking at npm yalc, and how it can be used to test your packages with examples based on the next structure.

Also, we will talk about why to choose yalc instead of npm link.

npm yalc

Yalc acts as simple local repository to share your local developed packages in your local environment. When you publish a package with yalc, the files that should be published to NPM are stored in a special global store.

Then if you add the package in another project, this project will pull the package content from this special global store, and injects a file:/link: dependency into package.json, and creates a local yalc.lock file to ensure consistency in the internal routines.

The usage of yalc is quite simple following next steps:

1. You need to install yalc globally on your machine:

   
   
     npm i yalc -g
   

2. You need to publish your fancy dependency library:  

      ```


      cd my-fancy-library 
      yalc publish

  This will copy all the files that should be published                   in a remote NPM registry. This means if your package has some lifecycle scripts, they will run with the publish.  
  To avoid the scripts, run:  

  ```

  cd my-fancy-library 
  yalc publish --no-scripts

3. To add this new locally published package to your awesome project:  

      ```


      cd my-awesome-project 
      yalc add @ks/my-fancy-library  

1. To update the dependency library, you can do it with an update:

   
   
     yalc update @ks/my-fancy-library 
   

      But if you have the same dependency on several dependent packages, you can push the changes to all of them in one command:

      ```


      yalc publish --push  

1. To finally remove the dependency from yalc in the dependent project:

   
   
     yalc remove @ks/my-fancy-library 
   

      or you can use --all flag to remove all the yalc packages from the project.



You can unpublish the library published on the second step with:  


  yalc installations clean @ks/my-fancy-library 



    

    

Use yalc instead of npm link

You might be wondering, why I use yalc instead of the npm link if they are very similar. I will give you some context about my projects first.

In my actual project, we have several UI-component libraries depending on others, working a little bit as a micro-frontend would work, but with more pyramidal hierarchy. They are typescript projects with storybook, babel, jest for testing... All of them are shared between several teams, with different node versions.

When the npm link is used, the project’s specific version of node will be used to create the link, and only the projects using the same version will be able to access the local version. Npm link doesn’t throw any errors when this happens.

Some of our projects have references to peerDependencies, and it’s very easy to stumble into issues with symlinks, as the projects' peerDependencies are not always resolved when needed.

Also, there are some documented errors like duplicated react when using npm link.

All of these issues are relatively easy to fix, but after running into them several times, we started to use yalc, and since then, there have not been any similar issues.

I hope you find this useful, please leave a comment in case of any question or feedback.