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 lib@1.0.1 # 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 ng serve.
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
change followSymlinks from false to true.