Sign in Get started Upcoming improvements to Angular library distribution

TLDR; In v12, we’ll deprecate our legacy compilation and rendering pipeline called View Engine. This change will not require any action by developers. Libraries dependent on View Engine will continue to work as expected via our compatibility compiler ngcc. If you’re a library author or interested in understanding technical details, please continue reading the sections below.

Angular’s new rendering and compilation pipeline, Ivy, has been the developers’ default experience for the past year. To ensure interoperability with the old pipeline, we maintain compatibility layers that have implications on development experience. In this post, you’ll learn our plan for moving away from the legacy compiler towards faster compilation and simplicity.
Ivy has been a multi-year effort to make Angular simpler, faster, and easier to maintain. We’ve been fine-tuning the balance between static checks and dynamic constructs to ensure Angular continues to provide type checking, efficient build-time optimizations, and fast change detection.
Starting with version 9, we enabled Ivy for all-new Angular applications and provided a smooth, automated update path. To ensure backward compatibility of applications with libraries using the previous rendering and compilation pipeline (View Engine), we developed a compatibility compiler called ngcc. You’ve probably noticed ngcc run after you create a new project or install a dependency.
Running the Angular compatibility compiler
Running the Angular compatibility compiler
ngcc is our way to compile View Engine libraries so that Ivy applications can consume them.
We spent a lot of time ensuring ngcc is fast, and we call it only when necessary, but it’s an extra step between installing your dependencies and running the project. Additionally, having libraries depending on View Engine means we can’t remove this legacy implementation, which has its own maintenance cost and would slow us down from evolving Angular.
To transition away from View Engine, we developed our Ivy Library Distribution plan and shared it as an RFC with the community. We collected a lot of fantastic feedback, and we released a preview implementation as part of Angular v11.2.
Moving away from View Engine
Currently, developers can use either Ivy or View Engine for their applications and libraries. To move the entire ecosystem to Ivy, we’d need to enable a smooth update path for both library and application developers.
Looking at the usage of --enableIvy flag in our telemetry, we saw that the vast majority of applications are currently using Ivy, which allows us to remove the --enableIvy flag and deprecate View Engine. Ivy applications can depend on View Engine libraries thanks to our compatibility compiler.
bar graph of applications opting out of Ivy
Applications opting out of Ivy
At the same time, all the libraries currently are in View Engine format. Developers can use all these libraries in Ivy applications and libraries thanks to the compatibility compiler, but not vice versa — View Engine libraries can’t depend on Ivy.
After many conversations with library authors and application developers, in v12 we’ll initiate a plan to move entirely to Ivy and unblock the removal of View Engine:
Deprecate View Engine and disable the functionality for creating new applications with it
Enable the Ivy library distribution by default for new library projects
To ensure smooth transitions of libraries dependent on Angular framework and components, we’ll continue distributing them in View Engine format. In v13 when the majority of third-party libraries are already using Ivy, we’re planning to transition Angular and components as well.
How does this affect you?
The changes apply only to new applications and libraries. There’s generally no action required for existing projects.
If you’re an application developer, this shouldn’t have any impact on your day-to-day development process. In case you’re currently relying on View Engine, make sure you move your app to Ivy.
If you’re building libraries and all your users are on Ivy, this change should not require any actions on your side unless you want to try the new Ivy library distribution format. In case View Engine applications or libraries are dependent on your library, we recommend to continue distributing it in a View Engine format. In v12 ensure you don’t opt into the Ivy library distribution until all the dependent libraries and applications move to Ivy.
Over time with the new Ivy Library Distribution on, both library and application developers will start seeing fewer ngcc compilations and, therefore, have better development experience.
How to opt out?
If you’re a library developer and you’re not ready to move to Ivy just yet, in v12 update your tsconfig.lib.prod.jsonto:
/* To learn more about this file see: https://angular.io/config/tsconfig. */
{
  "extends": "./tsconfig.lib.json",
  "compilerOptions": {
    "declarationMap": false
  },
  "angularCompilerOptions": {
    "enableIvy": false
  }
}
How can you help?
If you’re a library developer, you can test the new library distribution mechanism and give us feedback! You can use this configuration to enable Ivy library distribution for your existing View Engine libraries. Update your tsconfig.lib.prod.json to:
/* To learn more about this file see: https://angular.io/config/tsconfig. */
{
  "extends": "./tsconfig.lib.json",
  "compilerOptions": {
    "declarationMap": false
  },
  "angularCompilerOptions": {
    "enableIvy": true,
    "compilationMode": "partial"
  }
}
In case you hit any issues, please report them on GitHub.
If there are dependent libraries or applications that rely on View Engine, make sure you work with their authors to migrate them to Ivy before you enable Ivy library distribution for your packages.