Rebuilding or serving library project

[Nodarii]

Feature Request

Some interface that would rebuild library project that is generated with ng g library niceLib.
Of Course the best option would be ng serve niceLib or include it to the application serve. Or at least another build that allow to add --watch parameter like it does for for application. Here what I mean:

• for application we are allowed to run ng build --watch
• for library we have ng build niceLib
• but we can't use ng build niceLib --watch, as it throws Unknown option: '--watch'

[Tyler-V]

The new angular.json specifies a 'defaultProject' of which you generate and then are able to use the generate library command which creates the subsequent projects/ and updates the angular.json.

What I'm doing is using my 'defaultProject' as the demo app and then import { ProjectModule} from 'projects/name/src/public_api'.

When serving the app, any file changes inside 'defaultProject' or libraries projects/ reloads the development server.

[filipesilva]

Heya, this feature request is something we are aware of and talk about in https://github.com/angular/angular-cli/wiki/stories-create-library#why-do-i-need-to-build-the-library-everytime-i-make-changes.

In the future we want to add watch support to building libraries so it is faster to see changes.

We are also planning to add internal dependency support to Angular CLI. This means that Angular CLI would know your app depends on your library, and automatically rebuilds the library when the app needs it.

[beeman]

As a workaround you can use nodemon to rebuild the libraries:

npx nodemon -w ./projects/ui -e ts --exec 'ng build ui'

It's on the slow side but does get the job done. One downside is that you need to run a separate process for each of the libs you want to rebuild.

[hwangzhiming]

try File Watchers if you use WebStorm.

[giggio]

The proposal from @Tyler-V is by far the only acceptable at this moment. No developer can take the productivity hit that manually rebuilding the library causes. Even with an automated watcher the build time increases substantially. Until there is a fix I, differently from what the ng team proposes, will err on the side of productivity instead of caution.

[Tyler-V]

@giggio,

@filipesilva and @alan-agius4 worked on some changes this morning and I'm currently able to serve my library from my demo project as suggested and build all in --aot!

You can view the changes here, specifically the PR by filipesilva https://github.com/Tyler-V/ngx-easy

I believe changes were committed and merged on ng-packagr to support this.

ng-packagr/ng-packagr#862

[giggio]

BTW, to anyone interested, it is easier to, instead of using import { ProjectModule } from 'projects/lib/src/public_api' to simply change tsconfig.json to "lib": ["projects/lib/src/public_api"].

When there is an acceptable fix simply change this one line back to "lib": ["dist/lib"].

[giggio]

@Tyler-V That is awesome, but with what dependency and tools versions?

[Tyler-V]

@giggio

I'm using all @latest packages with the proper scoped lib configurations as suggested by @filipesilva

You can use my project as a reference on how I am serving my demo to develop the libraries with refresh.

[kyoz]

@giggio I also use that way 🐱. With projects do have UI. It's really paintful to rebuild library and re-run everytime we do have a change 😢