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 😢

[giggio]

@hansl how is this going to work and in what version of the CLI should we expect it? Is it 6.1.0 as per the milestone?

[alan-agius4]

@giggio, you can read the documentation here: https://github.com/angular/angular-cli/blob/master/docs/documentation/stories/create-library.md#why-do-i-need-to-build-the-library-everytime-i-make-changes

In a nutshell you'd need to run

ng build my-lib --watch

This will do a partial recompilation of the library, if you want to rebuild also the app when the library changes, you'd need to spawn 2 processed. One that watches the library and another that watches the application.

As far as the release, this won't be under 6.1.x, but should be under 6.2.x

[GeorgeKnap]

I've been using the ng build my-lib --watch for some time now but I 've been unhappy with the rebuild time.
Today I changed the default path mapping in main project's tsconfig to point to lib's public_api:

"paths": {
      "users": [
        "projects/users/src/public_api"
      ],
      "shared": [
        "projects/shared/src/public_api"
      ]
    }

now the libraries are built by ng serve command, changes propagates super fast and also the Chrome devtools are able to debug raw typescript files.
Sounds too good to be true but really works.

[kroeder]

@alan-agius4 we have a repo with 6 angular projects inside. Are there already plans on solving A depends on B while watching all projects?

If I watch A but B wasn't compiled yet, A fails. Do I have to manually know the dependencies of each library and start watch mode one after another?

Something like ng watch --all-projects would be super cool in my naive thinking process 😄

[playground]

@filipesilva how would you handle project with multiple library dependencies?
For example project A depends on lib-B and lib-C and lib-C depends on lib-D, if changes are made to lib-D, will building project A only compile lib-C and lib-D?

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.

[filipesilva]

@playground the CLI at the moment does not rebuild project dependencies at all. You have to manually build those libraries in separate processes, and you probably want to keep them in watch mode so the libraries are rebuilt.

[Noah1989]

On my machine rebuilding the library in a separate process triggers the rebuild of the main app too early and the resulting library code in the app is always one change behind. The solution by @GeorgeKnap works, though.

[vimalans]

@GeorgeKnap 's suggestion works!

[nickofthyme]

@GeorgeKnap you're a lifesaver! Thanks 🎉

[rdhelms]

@GeorgeKnap

Wow...so that really does work eerily well...do you know what the downsides are of using the projects path instead of dist? Surely there must be some reasons NOT to do that or else angular would have it be the default / recommended path?

[GeorgeKnap]

@rdhelms
The point is you are pointing to the library source, not the library output folder. That way ng serve works with source typescript files.
However I think this is good only for development. For prod environment I have the libraries built separately in npm feed and using them as any other 3rd party dependency.

Does it answer your question?

[giggio]

I came back to this, as it has been a while since I tried the whole "double watch" solution, and it could have improved on ng7.
Not at all. It is still much slower than running everything as a single project.
I have just updated my whole project and deps to version 7 and I can say it is better than before, but still to slow.
I hope a solution eventually comes up, until then I will keep using the tsconfig path remap.

[dmichael266]

@GeorgeKnap you just saved me a few hours a day probably! Can't thank you enough.

[wottpal]

@GeorgeKnap I guess your solution stopped working on Angular 8.2.0-next.0 (Ivy enabled) 😐
I'm getting an error:

ERROR in ENOENT: no such file or directory, scandir '/[...]/projects/lib/src/public_api'

This can of course be just a bug on the Angular-side but I couldn't find any according issue.

---

Update: I fixed it by changing the paths definition in tsconfig.json to "lib/*": [ "projects/lib/src/*" ] and changing all imports to import ... from 'lib/public_api'.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}