-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(core): respect packageGroup in nx migrate #9667
feat(core): respect packageGroup in nx migrate #9667
Conversation
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/nrwl/nx-dev/3t9n2TAFp1Zcqu1bW6yWGN5RRiTB [Deployment for d2969e8 canceled] |
"@nrwl/web", | ||
"@nrwl/js", | ||
"@nrwl/cli", | ||
"@nrwl/nx-cloud", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the ng-update
section remain here if nx-migrations
works the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It shouldn't be necessary for nx plugins, but there may be some cases in really old repos that have @nrwl/workspace installed as a plugin for angular CLI. @FrozenPandaz can you review this piece? I'm not sure if its still needed or not.
@AgentEnder @FrozenPandaz I know the PR is a lot, so please let me know if I can assist in any way, questions or whatever needed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @gioragutt! Thanks for the PR, its a large amount of work and contains some helpful clean ups too!
This is functionality that people have complained about missing for a while, and is something that should certainly be added imho. I'll work on getting a few additional reviews on this PR, since its large and touches some areas that recently changed.
- @FrozenPandaz: Do you care to give this a sanity check? Other than my notes it LGTM, but you may have some additional concerns + context.
- @leosvelperez: You recently changed a bit of things in
migrate.ts
to make it faster. Do you care to glance over the portions you touched that are also touched here and sanity check them?
Thanks again!
"@nrwl/web", | ||
"@nrwl/js", | ||
"@nrwl/cli", | ||
"@nrwl/nx-cloud", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It shouldn't be necessary for nx plugins, but there may be some cases in really old repos that have @nrwl/workspace installed as a plugin for angular CLI. @FrozenPandaz can you review this piece? I'm not sure if its still needed or not.
return { | ||
...acc, | ||
[pkg]: { | ||
version, | ||
alwaysAddToPackageJson: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we allow this part to be specc'd from the packageGroup object? Imagine a plugin introduces a new utils package, should they have to write a migration that installs it or should they be able to add it to packageGroup with alwaysAddToPackageJson
set to true?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I allow version
(to support nx-cloud
), I can definitely allow the rest of the keys if wanted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that all of them would be needed, and I actually think it may be fine to leave it as is. @FrozenPandaz opinion?
@gioragutt I think that CI should run properly on this PR now that I pushed up that empty commit, I'm not sure why Circle acts like this sometimes, you've got merged contributions so I'd expect it to work without me pushing 🤷 |
@AgentEnder there are failing tests in |
@AgentEnder had to revert the Perhaps it is worth re-iterating over it later, since it might create a more standard behavior, but currently fixing it would introduce a breaking change of And, as always, your commit is needed to trigger CI 😅 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM now 🎉 . Going to talk over changes with @vsavkin and @FrozenPandaz sometime this week before figuring out appropriate time to merge.
packages: migration.packageGroup.reduce((acc, packageConfig) => { | ||
const { package: pkg, version } = | ||
typeof packageConfig === 'string' | ||
? { package: packageConfig, version: targetVersion } | ||
: packageConfig; | ||
|
||
return { | ||
...acc, | ||
[pkg]: { | ||
version, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Talked to vsavkin a bit more, and there should probably be a recursive portion of this.
Collapse packages would need to support packages in the packageGroup, which also have a packageGroup themselves. There should also be some circular prevention. I.e.:
a: ['b', 'c',]
b: ['a', 'd']
c: []
d: []
nx migrate a
should expand into a, b, c
, then b should be expanded into b, a, d
, then c
and d
shouldn't expand since they have no group. The function would need to notice that its already expanded a
, and refrain from doing so when it handles expanding b
.
Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it does make sense, I'll make it recursive, and will try to make it a little more readable in the process, the code is pretty hard to read currently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AgentEnder @vsavkin I added a UT before starting to work on this, and I was surprised to see the test pass 😂
I looked at the code and than I saw that _updatePackageJson
already recursively calls itself, so this is already handled 👍🏻
I'll upload the test just so this will be covered.
0a3f70f
to
6b4dfda
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good, just found a small change during review with Jason. We are going to go ahead and merge, and put in the change real quick afterwards.
Thanks for the contribution @gioragutt
@@ -9,9 +9,15 @@ export interface NxProjectPackageJsonConfiguration { | |||
targets?: Record<string, PackageJsonTargetConfiguration>; | |||
} | |||
|
|||
export interface NxMigrationsConfiguration { | |||
migrations?: string; | |||
packageGroup?: (string | { package: string; version: string })[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Package group can be an object, defined as Record<packageName, version>
. I like the addition of being able to expand a single package and declare its version, so lets keep that but also add support for the format w/ version that angular specifies. For reference, check the package group in @angular/cli compared to @ngrx/store:
https://unpkg.com/@ngrx/store@13.1.0/package.json
https://unpkg.com/@angular/cli@13.3.2/package.json
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, that's a good idea, I wasn't aware that this was one of the formats. It should be easy enough to add support for this, as ResolvedMigrationConfiguration
is separated from NxMigrationConfiguration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we had some follow up work in migrate.ts anyways 😄
Awesome work @gioragutt! Thank you so much, we were actually planning on tackling this soon. LGTM 🎉 |
This pull request has already been merged/closed. If you experience issues related to these changes, please open a new issue referencing this pull request. |
Current Behavior
package.json#ng-update.packageGroup
is not respected bynx migrate
.Expected Behavior
The following configurations in
package.json
should work:Related Issue(s)
Fixes #4575