Solution for Smaller Unit Development (Lazy Compile Per Module or isolated app - but without the cost of micro front-end)

[Jonathan002]

🚀 Feature request

Command (mark with an x)

• new
• build
• [ x] serve
• test
• e2e
• [x ] generate
• add
• update
• lint
• extract-i18n
• run
• config
• help
• version
• doc

Description

A very large Angular App can take several minutes to compile, when only a Unit Module or Feature is needed for development. (E.g. Imagine Compiling all of Angular Material Components when only 1 material component module needs development.)

There have been proposed solutions that allow faster compile/development such as Micro Front Ends (Where a large app is broken into smaller embedded apps in the view). Although it is very wrong performance wise to have multiple angular apps in 1 view. (e.g. why bootstrap angular 5 times if the web app view used 5 micro front ends?)

https://speakerdeck.com/naltatis/bye-bye-frontend-monolith-accelerating-feature-development-with-micro-frontends?slide=36

Describe the solution you'd like

Allow developers to ng serve a spec file (single / module scoped) for development (in compile isolation to the rest of the app - the server can be reached via browser to view development results). A spec file should contain mock data needed to bootstrap itself to a micro app for development.

Below are 2 approches:

A: Unit Testing UI but for Development with Lazy Compile
I would like a feature where the angular cli has a navigatable UI environment (like how karama test runner opens the browser)
and allows us to choose Unit Testable modules for development work. Only the module selected is lazy compiled and it is fast to get up and running with development.

B: ng serve command per module
ng serve moduleName
The command can open a micro-app for unit development and faster compilation.

---

Angular is considered to be quite heavy that it is suggested to try other frameworks when using the micro front end pattern:

https://speakerdeck.com/naltatis/bye-bye-frontend-monolith-accelerating-feature-development-with-micro-frontends?slide=59

If a dev team decides to convert lazy route navigation into micro front ends as well, it really feels like we loose the benefit of a SPA if each new route has to get a new html document and bootstrap all over again, instead of updating the DOM quickly (if user goes back and forth multiple times)

We should seek to isolate in dev apps during development but still ship a single app that gives us the performance and speed of a SPA.

Describe alternatives you've considered

Have you considered any alternative solutions or workarounds?

[petebacondarwin]

Have you looked at https://storybook.js.org? I think this may provide a part of what you are looking for.

[Jonathan002]

@petebacondarwin Thank you for the reply. Yes Storybook seems really great for documenting and developing.

Although it still compiles the full app. (In case of a large codebase with 500+ components) I've found others try to use webpack loaders to lazy compile storybook as well.

liximomo/lazy-compile-webpack-plugin#13

To be more specific for my case, I work in an Nx workspace where I have libs/vendor folder with many (1 component only) modules to be imported in the main app.

I suppose, I'm hoping the feature would be an internal webpack config that can make lazy AngularModule compiling work seamlessly with Storybook or Nx.

ng add storybook (has lazy compile) or nx serve lib-project:module-name or
ng serve angulars-own-custom-ui-storybook (which has modules indexed in nav with lazy compile on nav click event)

I really hope you put this request into consideration.

[alan-agius4]

Hi @Jonathan002,

Thanks for this request. There are a number of things to consider here.

Prebuild your libraries before consuming them in your application
Many NX users use path mappings, to consume their libraries TS sources directly in their apps. We the Angular tooling team don't recommand this for a number of reasons.

1. End up turning your monorepo into a single application monolith compilation, which does cause slower compilatioms.
2. Inconsistencies, the libraries compilation pipeline is different from that of the application, a library also has certain restrictions such as lazy-loading and routing. Therefore including your libraries sources to be compiled as part of your application might yield unexpected behaviour.

Lazy/partial compilations
Webpack does offer a way to do lazy compilations https://webpack.js.org/configuration/experiments/#experimentslazycompilation.
That said this is very much experimental as it was only introduced a couple of weeks ago. This also doesn't effect the TSC/NGC compilation/analysis which needs to be done as a whole.

We will keep an eye on this feature.

Microfrontends
The buzz word! IMHO, these should only be considered if multiple independent teams are working on different parts of the application and you want to have seperate release cycles.

Other than that, it's likely be a footgun due to unnecessary increase of completely introduced to the project and build-pipeline.

Consistency
ng serve should be as close as possible to the "real thing" and the result of ng build.

---

We are consistently working to improving the performance and reduce compilation times.

In version 12.0.2 we did several changes to improve Sass compilation time by forcing usage of Sass sync API which at times can be 2x faster than the async version.

In version 12.1.x of the Angular CLI which is currently in pre-release, you can opt-in into an experimental persistent build cache which should improve the compilations times quite a lot
#20756

While, I thank you again for these requests. I don't see any of these to fall in the Angular CLI roadmap in the near future mainly because there are a number of UI testing frameworks and ng serve should be as close as possible to ng build.

[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.}