Skip to content
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

ng update on yarn workspace with migrations #17118

Closed
1 of 15 tasks
c-jasonk opened this issue Feb 28, 2020 · 2 comments
Closed
1 of 15 tasks

ng update on yarn workspace with migrations #17118

c-jasonk opened this issue Feb 28, 2020 · 2 comments

Comments

@c-jasonk
Copy link

c-jasonk commented Feb 28, 2020

🚀 Feature request

Command (mark with an x)

  • new
  • build
  • serve
  • test
  • e2e
  • generate
  • add
  • update
  • lint
  • xi18n
  • run
  • config
  • help
  • version
  • doc

Description

Migrations work great for libraries hosted in an npm repository. In a monorepo that uses yarn workspaces, there doesn't seem to be a great way to leverage them. If a shared library provides migrations but that library is consumed via yarn workspaces, that library never shows up in `ng update`. However, migrations can still be run `ng update my-shared-lib --from=1.0.0 --to=2.0.0 --migrate-only`. This is helpful for running shared migrations, but currently requires each migration run in this manner to be manually documented somewhere. If I were to run that in a given workspace, and then someone else later wanted to verify that the migration had been run, there wouldn't be any direct evidence of it. Additionally, when the next version of the shared library is "released" (in this case, version bumped as a result of new migrations being added), there isn't a good way to know what the next --from value should be unless someone else had previously documented the last --to value they used.

Describe the solution you'd like

For libraries consumed via yarn workspaces, or possibly for any library whose migrations are run via `--from=x.x.x --to=y.y.y --migrate-only`, it would be great if the most recent --to value was persisted in some manner and then compared against the latest version available. In the scenario above, after running `ng update my-shared-lib --from=1.0.0 --to=2.0.0 --migrate-only` and then updating my-shared-lib to 3.0.0, the result of a subsequent `ng update` might look like:
We analyzed your package.json, there are some packages to update:

  Name                               Version                  Command to update
 --------------------------------------------------------------------------------
  my-shared-lib                      2.0.0 -> 3.0.0           ng update my-shared-lib --from=2.0.0 --to=3.0.0 --migrate-only
@alan-agius4
Copy link
Collaborator

Hi, this has the same root cause as #14841

Let’s keep tracking it over there.

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Apr 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants