-
Notifications
You must be signed in to change notification settings - Fork 217
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
fix: usage of potentially wrong melos version during script execution #783
base: main
Are you sure you want to change the base?
Conversation
To view this pull requests documentation preview, visit the following URL: Documentation is deployed and generated using docs.page. |
daa7230
to
c040977
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.
From a quick glance it looks like a sound idea!
/// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, thanks for the quick review.
Is this a future enhancement request or already implemented? 🙂
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.
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_dependencies
might 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.
@spydon Am I correct in understanding that you're unhappy with the comment in the code? If so, could you suggest a better or more accurate phrasing? :)
Additionally, if the only remaining blocker for merging is the failing tests, I’d be happy to look into the breaking cod – given it's likely the changes will be merged. :)
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.
Can you also rebase this branch on main (or merge in main, whichever you prefer)?
It would be great to get this out into the v7.0.0 pre-release.
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 rebased the branch.
Before adding the proposed test I tried to fix 2 failing tests in run_test
.
Unfortunately I wasn't able to trace the issue down yet.
Will have another look in a few days.
Is there a way to see script output during test execution?
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.
❌ test/commands/run_test.dart: script supports passing additional arguments to scripts (exec) (failed)
ScriptException: The script hello failed to execute.
package:melos/src/commands/run.dart 70:7 _RunMixin.run
===== asynchronous gap ===========================
test/commands/run_test.dart 247:7 main.<fn>.<fn>
❎ test/commands/format_test.dart: Melos Format should run format with --output none and --set-exit-if-changed flag (skipped)
❌ test/commands/run_test.dart: script supports running "melos exec" script with "exec" options (failed)
ScriptException: The script test_script failed to execute.
package:melos/src/commands/run.dart 70:7 _RunMixin.run
===== asynchronous gap ===========================
test/commands/run_test.dart 318:7 main.<fn>.<fn>
Do the tests not fail locally for you?
There are also some analyze issues.
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 referring to the output created by the scripts used for testing. All it says is "test_script failed to execute" – but what output did it generate? I.e. why did it fail?
The tests fail locally for me.
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.
Hmm curious, if you comment out these lines: https://github.com/invertase/melos/blob/main/packages/melos/lib/src/commands/run.dart#L68-L71
you'll get an output with lots of these:
' Exception: Failed to run pub get:\n'
' Resolving dependencies...\n'
' \n'
' Error on line 1, column 7 of ../melos_test_THCNVC/pubspec.yaml: "name" field doesn\'t match expected name "melos".\n'
' ╷\n'
' 1 │ name: workspace\n'
' │ ^^^^^^^^^\n'
' ╵\n'
' \n'
'\n'
' /home/spydon/repos/melos/packages/melos/test/utils.dart 96:5 runPubGet\n'
@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. |
I'll close this for now since I don't think it will properly take the version in |
c1f5d00
to
6cd9e7a
Compare
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