Building an Angular 4 Component Library with the Angular CLI and ng-packagr
Nikolas LeBlanc

Hi there,

first to Nikolas, thanks for the article!

Then to all of you: there are a few ways to integrate ng-packagr in the Angular CLI in terms of the developer workflow. I now talk about using the library within the same project (like a “demo” application or the “aio” of Angular).

One, I used to do a “paths” mappingtsconfig.json in the past (pointing to the dist folder generated by ng-packagr). This has a few drawbacks like the need to re-compile the library every time you want to see it in the demo app.

Two, a good alternative is to use that “paths” mapping to the source files (i.e., paths: {"@my/lib": ["path-to/lib/public_api.ts"]}. Drawback here is that we’re building the library from sources in the demo app but keep publishing the dist artefacts (so you do not build the demo against the compiled and published version of the library).

Third, which I would prefer right now, is combining both approaches … i.e. have a dev build of the demo app that links via paths against the sources and have a prod build of the demo app that picks up the dist folder of ng-packagr. I find that this speeds up the development workflow, especially when building these sort of “Let’s componentize our corporate design in Angular!”-library (like ng-bootstrap, material, clarity, and so on…). This requires you to create a multi-app configuration in the Angular CLI — one configuration uses a w/ the mapping to sources, the other configuration links against the dist folder. Last, if possible for you (and you’re not stuck on Windows…), you could try around with symlinks instead of the “paths” in tsconfig … could be another alternative that speeds up the workflow.

I’ll attach doc links to TypeScript and Angular CLI for the configs:

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.