Is your feature request related to a problem? Please describe.
@angular-builders/jest and @angular-builders/custom-webpack should work with Angular 11
Describe the solution you'd like
Support Angular 11
Describe alternatives you've considered
None
Additional context
I am currently working on fixing the failing dependabot PRs #870 #871 and #872 and will provide a PR shortly.
@just-jeb you might also want to create a new 10.x.x branch for the Angular 10 release.
@jsone-studios thanks for your contribution!
A proper update process would include:
ng update in all the examples (which are also used as e2e test projects) and committing the updated codeAlso it wouldn't be a simple chore commit but a BREAKING change (in conventional commits !).
I'll create the 10.x.x branch.
Thanks for the detailed explanation. Step 1 should be already finished with my PR #874 and PRs from dependabot that have been auto merged. I am going to work on the other steps too. Should I add those changes to my already opened PR or should I create another PR for step 2 and step 3?
One PR is good.
I should probably disable dependabot for Angular packages since it's not the proper update flow.
Essentially step 1 is finished only for timestamp builder that is a very simple one and that's why it worked probably.
The rest of the dependencies aren't updated (exactly because examples should be updated properly along with the builder dependencies).
Pending #819
Released beta version, #819 will be handled separately before the release of the stable version.
@just-jeb we recently migrated jhipster to angular 11, but there is a discussion about if we should upgrade @angular-builders to 11 beta.
From my point of view:
@angular-builders/custom-webpack and angular version.@angular-builders/custom-webpack@^10 should be forbidden to work with angular@^11.@angular-builders should be considered a plugin of @angular/cliIf that's true, @angular-builders should have peer dependencies instead of hard dependencies on @angular-devkit and @angular/cli. For reference see https://nodejs.org/en/blog/npm/peer-dependencies/
Whats your opinion?
@mshima Thanks for bringing it up. I discussed this issue a few times with Angular team and we agreed that the best approach is to keep Angular deps as direct dependencies rather than peer dependencies.
There are a few reasons for this, but mainly is that you (as a user) won't have to worry about alignment between Angular Builders and Angular packages. For instance @angular-builers/custom-webpack uses 3 of them - architect, build-angular and core. If we had it as a peer dependency (as it actually was before version 9 came out) then you (as a user) would have to explicitly install the right versions of all the 3 packages custom-webpack depends on, since modules hoisting is considered an implementation detail of the package manager. Otherwise it might not work, just like in #426.
Builders directly depending on Angular packages relieve you from this burden, while taking care of breaking changes in major versions (and there are some). The only thing you should take care of is keeping your builders version aligned with Angular version.
WDYT?
Hello @jsone-studios, just took a look at @angular/cli packages and they use the same approach, everything as a hard dependency.
Different from @angular/angular packages, they have peer dependencies on each other.
The reason should be that @angular/cli must run standalone, so every package that @angular/cli depends on, cannot have peer dependencies. Otherwise it would not install correctly on npm 6.
NPM 7 installs peer dependencies by default and tries to keep peer contracts.
When I tried to install @angular/common@^10 on an angular@^11 project, it fails with peer problem (npm 7):
$ npm install @angular/common@^10
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: [email protected]
npm ERR! Found: @angular/[email protected]
npm ERR! node_modules/@angular/core
npm ERR! @angular/core@"~11.0.1" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer @angular/core@"10.2.3" from @angular/[email protected]
npm ERR! node_modules/@angular/common
npm ERR! @angular/common@"^10" from the root project
When I tried to install @angular/cli@^10 on an angular@^11 project, it succeeds:
$npm install @angular/cli@^10
added 34 packages, changed 7 packages, and audited 1533 packages in 14s
80 packages are looking for funding
run `npm fund` for details
found 0 vulnerabilities
But fails to run:
$ npx ng serve
This version of CLI is only compatible with Angular versions 0.0.0 || ^10.0.0-beta || >=10.0.0 <11.0.0,
but Angular version 11.0.2 was found instead.
I have no idea if mixing @angular-builders with unsupported angular can generate a broken application.
Is there any potential problem of building an angular 11 application with @angular-builers/custom-webpack@^10 or @angular-builers/custom-webpack@^9?
$ npm install @angular/cli @angular-builders/custom-webpack@^10
$ npm ls --depth 1
cli@ /Users/mshima/test/cli
βββ¬ @angular-builders/[email protected]
β βββ @angular-devkit/[email protected]
β βββ @angular-devkit/[email protected]
β βββ @angular-devkit/[email protected]
β βββ [email protected]
β βββ [email protected]
β βββ [email protected]
βββ¬ @angular/[email protected]
βββ @angular-devkit/[email protected]
βββ @angular-devkit/[email protected]
βββ @angular-devkit/[email protected]
...
At first glance, everything seems to work. The application builds and runs.
If the result is at least doubtful, I see that @angular-builders has 2 options to resolve:
I hope this can be helpful.
Hey, thanks for the detailed response.
One potential problem is a schema mismatch (as you can see from the commit link I gave there are some changes in angular.json). But a bigger problem is that you essentially build your application with Angular CLI 10, not 11. So any changes that they did in the build process become irrelevant. The reason is that by depending directly on the Angular packages Angular Builders use the code of the specific version of these packages. So I highly recommend you not to do that.
As I mentioned before I cannot target the builders to a specific package manager. It can be npm 6, npm 7, yarn 1, yarn 2, fnmp you name it.
So what I see is a right approach is that Angular packages should be direct dependencies of the builders.
However, I'm still struggling to understand - why the documentation mentioning that the latest version of builders works with Angular CLI 11 and for earlier versions you should use corresponding version is not enough?
@just-jeb thanks.
But a bigger problem is that you essentially build your application with Angular CLI 10, not 11. So any changes that they did in the build process become irrelevant. The reason is that by depending directly on the Angular packages Angular Builders use the code of the specific version of these packages. So I highly recommend you not to do that.
That's what I was thinking when I brought this subject here.
However, I'm still struggling to understand - why the documentation mentioning that the latest version of builders works with Angular CLI 11 and for earlier versions you should use corresponding version is not enough?
That's really easy to ignore since everything seems to work. As you can see at follow up to my proposal to bump @angular-builder to 11.0.0-beta.1 https://github.com/jhipster/generator-jhipster/pull/13035#issuecomment-730023126.
I suggest to:
@angular/cli@^11 for:@dependabot to know about this contract.Warning: Using `@angular-builder/custom-webpack` will make the compile process to use `@angular-devkit/*` from `@angular-builder` dependencies, replacing the entire build stack.
- Using `@angular/cli@^11` with `@angular-builder/webpack-custom@^10` will effectively use `@angular/cli@^10`.
- Consider checking if `@angular-builder/custom-webpack` dependencies have been updated(deduped) correctly with `npm ls βdepth 1`.β¨
I'll take your suggestion into consideration and update the README in order to emphasize the importance of versions alignment. Adding peer dependencies would be wrong in my opinion, since it suggests that you have to explicitly install all the dependencies while you don't (and it wouldn't really help if you did).
I understand that upgrading to a beta version is not the best solution you could wish for, but it's all you've got unfortunately.
Stable version will be released after breaking change from #819 is implemented, which, in turn, blocked by this PR and this issue in webpack-merge.
That being said this is the only breaking change expected in v11 so for now the beta version is safe to use.
Great, @angular/cli peer dependency could be set as optional, so if installed the package manager should try to keep the contract.
See https://github.com/npm/rfcs/blob/latest/implemented/0030-no-install-optional-peer-deps.md.
Thanks for the clarification.
Most helpful comment
I'll take your suggestion into consideration and update the README in order to emphasize the importance of versions alignment. Adding peer dependencies would be wrong in my opinion, since it suggests that you have to explicitly install all the dependencies while you don't (and it wouldn't really help if you did).
I understand that upgrading to a beta version is not the best solution you could wish for, but it's all you've got unfortunately.
Stable version will be released after breaking change from #819 is implemented, which, in turn, blocked by this PR and this issue in webpack-merge.
That being said this is the only breaking change expected in
v11so for now thebetaversion is safe to use.