fix: usage of potentially wrong melos version during script execution #783
Conversation
|
To view this pull requests documentation preview, visit the following URL: Documentation is deployed and generated using docs.page. |
|
|
bspinner
force-pushed
the
fix/executable_path_handling
branch
from
daa7230
to
c040977
Compare
bspinner
changed the title
bspinner
changed the title
| /// i.e. usually the globally activated version. If there is one. | ||
| /// | ||
| /// This can cause issues when melos is started with `dart run melos`, | ||
| /// which will prefer the melos version specified via (dev_)dependencies. |
There was a problem hiding this comment.
Melos should always run scripts etc with the version that is defined in dev_dependencies, even if it is started directly from the version on path.
There was a problem hiding this comment.
Oh, thanks for the quick review.
Is this a future enhancement request or already implemented? 🙂
There was a problem hiding this comment.
The overarching goal of this PR is to eliminate ambiguity and surprises in the build process of Dart/Flutter applications. In line with that, I believe it would be ideal for Melos to behave in a consistent and predictable way.
Here’s what I think could be considered "unexpected" behavior:
- If Melos uses different versions of itself for script execution (i.e. for subprocesses of itself)
- This will be addressed with this PR!? :)
- If Melos silently switches to a different version at startup (i.e., in the main process)
- This could be especially challenging when intentionally testing a specific version.
- Perhaps an optional strict mode (e.g., for CI environments) could help, where Melos would verify that its version matches the one specified in
pubspec.lock.- The version in
dev_dependenciesmight only define a minimum version, which wouldn’t fully address this, as you likely know as well. :)
- The version in
There was a problem hiding this comment.
Is this a future enhancement request or already implemented? 🙂
It's already implemented, try pinning you melos version to an older version an see what happens. :)
The version in dev_dependencies might only define a minimum version, which wouldn’t fully address this, as you likely know as well. :)
If one wants a specific version of melos, why not just pin the version in pubspec? I don't see the need for any separate feature for this.
|
@spydon I'm unsure if this could/should/must be applied to other places as well, since this is the first time I had a look at the code. |
Description
See long comment at https://github.com/invertase/melos/pull/783/files#diff-35f09e1c67ac8d5bd4889489c6ce0f6dc320b1491828444f2eca21c0f8ff765cR343 :)
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