[Feature Request] Support specifying which version of Angular Package Format to use

Type of Issue

[ ] Bug Report
[X ] Feature Request

Description

Currently each major version of ng-packagr only supports one version of the Angular Package Format, thus only targets one version of Angular:

• 1.x supports Angular 4
• 2.x supports Angular 5
• 3.x supports Angular 6

#344 Demonstrates that a package built targeting Angular 5 cannot be consumed by Angular 4. As a library developer, I want my package to be consumed by as many versions of Angular as possible.

I know I can simply stick to the 1.x version of ng-packagr to target Angular 4, but I still want to have all of the other goodies and bug fixes that you are releasing with the latest version.

I propose having some kind of command-line switch or a property added to ng-package.schema.json that would support specifying which version of the APF I want to target.

[dherges]

It’s a matrix-compatibility thing.

Thoughts:

1. Angular compiler 5 introduced metadata version 4. You cannot use metadata v4 in Angular 4 or prior.
2. APF is a set of artefacts trying to support a broad range of tools. You will be able to create an APF 6 package that continues to work even with older versions of Angular as long as you used an “appropriate” compiler version. (In fact, the angular compiler has version constraints on typescript and that’s why ng-packagr uses the typescript and angular compiler version that the user has already installed in the project).
3. However, by the evolution of the Angular tooling some features (e.g. resource inlining) are being moved to the Angular compiler and thus (partially) removed from ng-packagr. At that point, ng-packagr has some version constraints on the angular compiler version (much like angular has on typescript).
4. In turn, ng-packagr has version constraints on angular compiler and that has version constraints on typescript and on and on and on. At some point, it implies constraints on both authors and consumers of a library. Example: you won’t get an Angular 6-compiled metadata v4 library to go get to work in an Angular 4 app.

As you said there are much factors influencing what versions are supported. That’s where the “matrix-compatibility” term comes in. It’s at most possible to support a limited set of version combinations. And it’s impossible to make any guarantees or long-term plans for such upfront. Right now, ng-packagr@3 works with both ng@5 and ng@6 but who am I to know whether that continues in ng@7? I do not know the future 🌵

Conclusion for me:

• If you want the new and shiny things, go update.
• v1 will continue to work
• v2 will continue to work

[cyrilletuzi]

Sooner or later, this feature need to be done, even if it is difficult.

You should always encourage your users to migrate to the latest version and not have legacy code.

Even in a dream world where everyone want and can update quickly, it is absolutely impossible that all Angular apps are up to date on day one of a new major release. So even in this dream world, there is a least a few days/weeks/months where some apps will be on the older version, and some others will already be updated.

In fact, now that ng-packagr is an official part of the CLI, this feature is a requirement if Angular wants to respect LTS support.

One option would be to have a directory for each major version with its own node_modules.

As a library author, this issue is why I don’t use ng-packagr as I want to provide proper LTS support for users.