Recently I was working on a project, which consisted of multiple separate angular apps, with a handful of angular libraries of shared code. The project used angular 5, which doesn’t have any native tools for generating libraries, yet. So, we had to use ng-packagr to generate our custom angular libraries.
The main problem with such project architecture is that it makes local development into a constant juggling of multiple terminal windows, where you try to build one project just to pull it immediately into a different one.
I’ve seen it done in many different ways. Some of them are worth than another, some are better.
~ $ cd lib # in a library ~/lib $ vi code.js # make code changes ~/lib $ npm run build # generate a new build ~/lib $ git commit -am 'potato' # commit changes ~/lib $ npm version 1.0.1 # increment version following semver ~/lib $ npm publish # publish to a package manager ~/lib $ cd ../app # in an app ~/app $ npm install -S email@example.com # install a new version of a lib ~/app $ ng serve # preview the changes
This will result in the publishing of a new package version every time we would want to test a code. It’s a terrible idea, even if you use pre-release versions there is still no justification in polluting your package manager with a ton of dev versions of questionable stability.
~ $ cd lib # in a library ~/lib $ vi code.js # make code changes ~/lib $ npm run build # generate a new build ~/lib $ npm pack # pack a new version of a lib ~/lib $ cd ../app # in an app ~/app $ npm uninstall -S lib # uninstall an old version of a lib ~/app $ npm install ../lib/lib.tar # install lib from local .tar file ~/app $ ng serve # preview the changes
Pros: You don’t publish a new version of a library every time you need to test something. Another plus is that you don’t even need to commit any of your code changes.
Cons: You need to
pack and reinstall a new library version every time you make any changes
~ $ cd ../lib # in a library ~/lib $ npm link # make code changes ~/lib $ npm run build # generate a new build ~/lib $ cd ../app # in an app ~/app $ npm link lib # link lib package to an app ~/app $ ng serve --preserve-symlinks # run a livereload server
The main benefit of this option is that you will be able to fully benefit from a livereload server, as you will be able to focus on developing a library, and see changes in real time in your app running live in a browser.
Currently, there is an open bug in a
watchpack package, used by
This bug prevents livereload to pick up changes in symlinked directories in node_modules.
As a workaround, you just need to edit
node_modules\watchpack\lib\DirectoryWatcher.js file in your app and