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
- ...
- You set up your repository with git using the provider you prefer (github, gitlab, ...)
- You can choose to use a boilerplate for the framework you wish to use (Typescript, React, both, ...)
-
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
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.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 recursivelyChoose 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 fromcaret
totilde
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:
- Build the latest version of your code
- Use
npm pack
in the repository of your library This creates a tarball file you can move to the repository of the app you want QA to test it with.
Runmv nameoftarball ../wherever/your_app/lives
Thencd ../wherever/your_app/lives && npm i nameoftarball
Commit, push, deploy to a staging/test environment
When you get the all clear, whatever you deploy will be spot-on!
Top comments (0)