How to make your life easier when developing a front-end library

Let's say you have a good use case to develop a front-end library.

It could be that:

• you're re-using a lot of similar components in different apps
• you want to decouple your apps from an external api
• you want to play around with javascript for the fun of it
• ...

1. You set up your repository with git using the provider you prefer (github, gitlab, ...)
2. You can choose to use a boilerplate for the framework you wish to use (Typescript, React, both, ...)

3. Once you have done this, you realize that in order to integrate with your app:

   • you need to run a build depending on the bundling manager you use (rollup, webpack, ...)
   • you need to tell your app where to find the package being developed

4. At this point, I would advise using link, a command which exists both for yarn and npm.
   This creates a symbolic link between your app and the library you're working on.

5. To avoid having to "manually" rebuild after each code change in the library, use your bundler cli with the watch flag to watch the files recursively

6. Choose a test framework and you're ready to go!

Gotchas:

• running install at any point after this will overwrite the link.
• be mindful of what locks the version in your package.json in doubt, you could switch from caret to tilde or lock onto exact versions (with the --save-exact flag)

CODE, SWEAT, SWEAR AND TEST

Before deploying and publishing a package that needs code-review and QA:

1. Build the latest version of your code
2. Use npm pack in the repository of your library

3. This creates a tarball file you can move to the repository of the app you want QA to test it with.
   Run mv nameoftarball ../wherever/your_app/lives
   Then cd ../wherever/your_app/lives && npm i nameoftarball

4. Commit, push, deploy to a staging/test environment

5. When you get the all clear, whatever you deploy will be spot-on!