ng-packagr / ng-packagr

Compile and package Angular libraries in Angular Package Format (APF)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Ability to build single entry point only

Carlosamouco opened this issue · comments

Type of Issue

[ ] Bug Report
[X] Feature Request

Description

When developing an Angular library, I want to be able to recompile only the entry point / sub entry point that I am working on.

Currently, when I am building a library in watch mode, all the entry points that depend on the entry point that I am working on are recompiled even when I don't make any changes that affect the public API of that entry point.

Even though this is the intended behaviour, it slows a lot the development processes when there are multiple dependent entry points that are being recompiled for no reason. Also, if I have an application consuming this library with live reloading through "ng serve", it ends up taking considerable time to apply the change due to all the recompilations of the entry points that happen in the library, and it makes testing the change very painful and slow.

How To Reproduce

Considering a package named "my-lib"
Have at least two entry points:

  • my-lib
  • my-lib/sub
  1. Make the "my-lib" import the "my-lib/sub" entry point.
  2. Change anything in "my-lib/sub".
  3. Both entry points are always recompiled even when there isn't anything changing in the public API of the "my-lib/sub".

Expected Behaviour

Have a flag in the build command that allows us to define which entry points we want to watch for changes. For the first build, all the entry points should be compiled as usual.

ex: ng build my-lib --watch /sub

This would improve the development experience considerably.

Duplicate of #925

I read the thread in #925. Is this still not planed? Is there any known tooling that I can use to achieve this or any way to customize the ng-packagr?

Indeed, this is still not planned.

No, it is not possible to customize ng-packagr to build only a single entry-point.

Would you consider discussing how it should be implemented and accept a PR for this? Or do you think it does not make sense to include such feature in here?
Personally I think It would be a great improvement in the developer experience.

It isn't something hard to do right?

This would be a very large effort to do as ng-packagr was designed to build all entry-points and in general I am not onboard with adding support to compile a single entry-point.

IMHO, it will not improve DX, as if you change an another entry-point you would need to termite the process and start a new one, which would cause an even slower compilation as the in memory state is lost. During watch mode, only effected entry-points are partially rebuild/typechecked, thus I don't think that rebuilding a single entry-point would improve the build times by much.

In the case you are experiencing differently please open a new issue with a reproduction that we can look at.

I took a look at the code, and I think there are a couple of thing that would help allot when it comes to application rebuilding after triggering a recompilation of a library.

From the tests that I preformed, there are a couple of things that are performed during the build of affected entry points that would be nice if they were skipped.

I think that, only the directly changed entry point should touch the version of the package.json file, rebuild and flatten the code. Other dependent entry points should just perform type checking and not emit anything to not trigger unnecessary rebuilding's of the application. It would also be nice to have a setting to skip type checking of affected libraries during development, when we are running the "ng serve" since type checking is also performed at the app level if we have "skipLibCheck" set to false.

Since I am diverging from my initial request, I will open a new issue following this.

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

This action has been performed automatically by a bot.