Promoting @angular-devkit packages to stable semver

[BorntraegerMarc]

🚀 Feature request

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

Description

To prevent issues like this it would be great if the @angular-devkit libs follow the same semantic versioning as the main @angular packages.

Describe the solution you'd like

So e.g. instead of releasing the next major version as @angular-devkit/architect@0.1200.0 to release it as @angular-devkit/architect@12.0.0

This way semver checks will mork more reliably throughout the angular community.

Describe alternatives you've considered

NOTE: I have tried to search for existing open issues that describe the same feature request. Didn't find one. I'll be gladly closing this issue for another one if you could just point me in the right direction.

[alan-agius4]

Hi,

The reason why this packages follow a different versioning mechanism is because the API of these packages is not stable. Although, we try not to do breaking changes outside of major, as per Semver rules packages without a major version can contain breaking changes in any version. https://proxy-ga.blitzz.co/proxy/123456/semver.org/#spec-item-4

Issue: ionic-team/angular-toolkit#250

warning " > @ionic/angular-toolkit@2.2.0" has unmet peer dependency "@angular-devkit/architect@>=0.800.0".
warning " > @ionic/angular-toolkit@2.2.0" has unmet peer dependency "@angular-devkit/core@>=8.0.0".
warning " > @ionic/angular-toolkit@2.2.0" has unmet peer dependency "@angular-devkit/schematics@>=8.0.0".

With regards to the linked issue ionic-team/angular-toolkit#250, this appears to be more of an @ionic/angular-toolkit bug.

The above mentioned packages are typically not installed in the users workspace and hence defining them as peer dependency is not the correct approach. This is because for this to work the packages need to be hoisted in the correct location by the package managers, which is not always the case. Therefore, in this case the best course of action would be to change these dependencies to be direct dependencies.

Issue #19957
The root cause of the problem here is a defect in NPM 7. See #19957 (comment) and npm/cli#2553

Issue ionic-team/angular-toolkit#437

Package "@ionic/angular-toolkit" has an incompatible peer dependency to "@angular-devkit/architect" (requires "^0.1100.0", would install "0.1101.0")
Package "@ionic/angular-toolkit" has an incompatible peer dependency to "@angular-devkit/build-angular" (requires "^0.1100.0", would install "0.1101.0")

This also appears to be an Ionic issue in their peer dependencies definitions for two reasons.

1. @angular-devkit/architect", is not a direct dependency in the users project hence, again in this case @ionic/angular-toolkit are relying on module hosting.
2. @angular-devkit/build-angular, the current versioning used for this package https://proxy-ga.blitzz.co/proxy/123456/github.com/ionic-team/angular-toolkit/blob/2185e50aa3e9bdc11115b71045f3ecd6c0e199a7/package.json#L75 will only match patch versions. This is because when a package is not stable hence there is no major version. ^ is equivalent to ~. I think in this case Ionic would want to use >=0.1100.0 <0.1200.0, if they want to support all minor versions. The formula for experimental packages version is; "0." + (major * 100 + minor) + "." + patch. So, for example, the 11.1.0 release becomes the 0.1101.0 version for experimental packages.

Promoting these packages to stable is definitely something that we do want to do. But that does entitle some work like:

• Revisit the entire API of some packages
• Documentation
• Potential some packages will need to be conciliated

All in all, I do think that experimental versioning can be confusing, but we are abiding fully to the Semver rules. If anything we going beyond that and try not to do breaking changes in minor unstable versions.

FYI: @mhartington from Ionic

[BorntraegerMarc]

Maybe I should change the title of this issue to Promoting @angular-devkit packages to stable semver? Because that's what I was going for.

I don't know how far off these packages are actually from being stable but by the sound of your last comment they seem pretty stable. Plus not even considering that these packages & angular 2 has been out for over 4 years and are used in many prod envs 🙂

Is there a current plan when @angular-devkit packages should become stable?

[alan-agius4]

It’s tentative for version 12.

[BorntraegerMarc]

Nice! Thx for the info.

Is there another issue to follow progress? If yes, I’ll just go ahead and close this one.

[alan-agius4]

@BorntraegerMarc, as far as I know there isn’t.

[mhartington]

Thank you for the detailed explanation @alan-agius4. I'll go back and take a look at our deps for angular-toolkit and get them cleaned up.

[alan-agius4]

Closing since in version 12, most of the packages have been promoted to stable.

We will evaluate the status @angular-devkit/build-optimizer, @angular-devkit/architect, @angular-devkit/architect-cli and @angular-devkit/build-webpack in the near future.

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