feat!: Migrate to use the Pub workspaces feature #816
Conversation
|
To view this pull requests documentation preview, visit the following URL: Documentation is deployed and generated using docs.page. |
| After the [Pub Workspaces feature](https://dart.dev/tools/pub/workspaces) was | ||
| introduced in Dart 3.6.0, it is no longer strictly necessary to run `melos | ||
| bootstrap`, since all the packages are already linked together. However, there | ||
| are still some benefits to running `melos bootstrap`, because you need to run | ||
| `pub get` in each package to initialize the workspace, and `melos bootstrap` | ||
| will do that for you. |
There was a problem hiding this comment.
because you need to run
pub getin each package to initialize the workspace
@spydon I've just been running dart pub get in any folder (in a non-Melos workspace) and it initializes the whole workspace. That makes sense to me because the packages have a shared resolution.
There was a problem hiding this comment.
Ah, you're correct!
I read the instructions here sloppily: https://dart.dev/tools/pub/workspaces
You need to run dart pub get once for each package.
But that section is of course about if you aren't using the pub workspaces feature.
There was a problem hiding this comment.
Might not a matter of interpretation but this paragraphs reads to me as:
Once you start using Pub Workspaces, you don't need to run
melos bootstrap, but it's still convenient since it will rundart pub getin each sub-package for you
(It does say "each package in the _workspace" too!)
It would probably help to re-word this paragraph to specifically discuss how Melos and melos bootstrap play with the Workspaces feature. In general I had a hard time finding a list of what Melos can do that workspaces cannot (eg, specify that Melos can publish all sub-packages while pub cannot, but other pub commands do work recursively)
There was a problem hiding this comment.
Fixed it up here: #822
There was a problem hiding this comment.
Missed you second comment!
Yeah, I guess that we should clarify that on the intro page of the docs, is it something you'd like to PR? :)
There was a problem hiding this comment.
Ah, I don't actually know the details of melos -- that's why I came here, was hoping to find such a list!
<!-- Thanks for contributing! Provide a description of your changes below and a general summary in the title Please look at the following checklist to ensure that your PR can be accepted quickly: --> ## Description We no longer need to run `pub get` in all packages, in one package, or the workspace root is enough. Fixes the issue mentioned here: #816 (comment) ## Type of Change <!--- Put an `x` in all the boxes that apply: --> - [ ] ✨ `feat` -- New feature (non-breaking change which adds functionality) - [x] 🛠️ `fix` -- Bug fix (non-breaking change which fixes an issue) - [ ] ❌ `!` -- Breaking change (fix or feature that would cause existing functionality to change) - [ ] 🧹 `refactor` -- Code refactor - [ ] ✅ `ci` -- Build configuration change - [ ] 📝 `docs` -- Documentation - [ ] 🗑️ `chore` -- Chore
Description
This PR migrates so that we rely on the pub workspaces feature instead of creating the pubspec_overrides.yaml file.
Docs update and migration instructions are soon coming up.
Closes: #747
Type of Change
feat-- New feature (non-breaking change which adds functionality)fix-- Bug fix (non-breaking change which fixes an issue)!-- Breaking change (fix or feature that would cause existing functionality to change)refactor-- Code refactorci-- Build configuration changedocs-- Documentationchore-- Chore