request: support `--no-pub`

[lishaduck]

Is there an existing feature request for this?

• [X] I have searched the existing issues.

Command

No response

Description

The Flutter and Dart CLIs offer an option to turn off calling pub get before they run, which slows them down. It's called --no-pub, and can be passed to analyze, test (although Melos doesn't have a test command), etc.

Reasoning

I'm on a rather limited machine, so reducing redundant work is important. pub get can take up to a minute, and while pub workspaces will unify most stuff, they'll also (probably) slow down pub get even more.

Additional context and comments

Alternatively, passing unknown flags to the underlying command might work as well.

[spydon]

Makes sense, would you be interested in working on that issue?

[lishaduck]

Makes sense, would you be interested in working on that issue?

Interested, yes; actually do it, probably someday? 😁 ~~Now that I think about it, it'd probably be a good introduction before I tackle #747 (I plan on getting to that if no one else does, but I'm pretty busy with other obligations at the moment).~~ (Oh, you're doing that in #816. Thanks!)

[FranRiadigos]

Hi,

As of version 7.0.0-dev.9, melos bootstrap runs pub get before propagating shared dependencies. This makes a contradiction with that functionality. Should propagate first and then run pub get.

For example: In our monorepo we have a dep that, say requires meta version 2, while most of our packages use meta 1. Once you switch the dep with the meta version 2 requirement, since the bootstrap runs pub get earlier, it simply crashes with a dep conflict, regardless if you update the shared meta dep, since shared deps never get to the propagation process. (So one ends up manually replacing everywhere, hence not strictly a blocker)

I saw on https://github.com/invertase/melos/pull/816 it's been added an --offline mode That's actually not --no-pub, and I was hoping to see whether this was implemented to kind a sort this issue out

Since all of us are generally busy, not sure if I can dig into fixing this earlier pub get issue, but I consider it a bug.

Please, let me know if I'm wrong or if there's any quick workaround apart from manually replacing

@spydon @exaby73

Thanks, Fran

[spydon]

Should propagate first and then run pub get.

Unfortunately it can't, because the initial pub get gets the Melos version that is going to be used for the execution of the command.

In our monorepo we have a dep that, say requires meta version 2, while most of our packages use meta 1.

If you only update this version through common dependencies you should not be able to get into this situation, if pub get doesn't resolve after updating dependencies it will do a rollback. So you must have updated some dependencies manually to start with?

I'll have a look if it is possible to add --no-pub easily, but I think it might be problematic for the initial pub get, which --offline isn't handing either. (--offline existed before #816 btw, it was only some doc formatting that changed for it in that PR.)

[spydon]

If the cli_launcher package updated so that it could take in flags for dart pub get I think we could support this properly, this is where it is used: https://github.com/blaugold/cli_launcher/blob/main/lib/cli_launcher.dart#L191-L205.

[FranRiadigos]

because the initial pub get gets the Melos version

Ok, thought _setSharedDependenciesForPackage could be isolated somehow but I see it depends on cli_launcher.

So you must have updated some dependencies manually to start with?

True, nice spot! I had an SDK mismatch and ended up manually upgrading the project SDK + package. Now using the environment property to propagate and rearrange things. Dependency hell!

If the cli_launcher package updated

Seems like no updates since 2 years ago :(

We faced similar issues and ended up creating a custom script that installs our CLI binary in usr/local/bin to have always a version available, similar to how Firebase Tools standalone script works. But I guess depending on dart pub global installs makes it complex. No idea really.

Thanks @spydon

[spydon]

We can now go ahead and do this since https://github.com/blaugold/cli_launcher/issues/10 is released. I'm quite busy with organizing Flutter & Friends at the moment, is anyone else keen on putting up a PR for this and I can review it?

[foxanna]

Bumping this up to see if @spydon now has more time 🙂 I can contribute too, if you give me a hint on where to start 🙂

[spydon]

@foxanna it should only be a matter of updating to the newest version of cli_launcher and propagate the new flag to it in here: https://github.com/invertase/melos/blob/main/packages%2Fmelos%2Fbin%2Fmelos.dart

If you want to take on that task I'll assign you to the ticket. :)

[foxanna]

@spydon, sure, let me try that 🙂

[foxanna]

@spydon, I looked into the issue more closely, and wanted to hear your thoughts on the following.

Currently, Melos on its latest main branch is already using cli_launcher v0.3.2+1, which includes the support of LocalLaunchConfig added here. The LaunchConfig.resolveLocalLaunchConfig is not yet used in packages/melos/bin/melos.dart, but updating it to:

import 'package:cli_launcher/cli_launcher.dart';
import 'package:melos/src/command_runner.dart';

Future<void> main(List<String> arguments) async => launchExecutable(
  arguments,
  LaunchConfig(
    name: ExecutableName('melos'),
    launchFromSelf: false,
    entrypoint: melosEntryPoint,
    resolveLocalLaunchConfig: (_) async => LocalLaunchConfig(pubGetArgs: ['--verbose']),
  ),
);

does not seem to make any difference, and pub get is getting executed without --verbose flag. I am making this conclusion just by looking at the output of melos list --cycles command, which decides to execute pub get before detecting cycles. Let me know if this is not the correct way to test it.

But setting this aside, I am concerned if LocalLaunchConfig is supposed to help with implementing the --no-pub flag at all. Looking at cli_launcher here, it decides to update dependencies without any configuration, and only provides a way to configure dart pub get parameters, not to cancel the command altogether.

Perhaps I am missing some context about Melos and its usage of cli_launcher, which makes it hard to suggest a working fix for this task.

[spydon]

does not seem to make any difference, and pub get is getting executed without --verbose flag. I am making this conclusion just by looking at the output of melos list --cycles command, which decides to execute pub get before detecting cycles. Let me know if this is not the correct way to test it.

Maybe cli_launcher isn't outputting the result from the initial pub get to stdout?

But setting this aside, I am concerned if LocalLaunchConfig is supposed to help with implementing the --no-pub flag at all. Looking at cli_launcher here, it decides to update dependencies without any configuration, and only provides a way to configure dart pub get parameters, not to cancel the command altogether.

I guess that needs to be another PR to cli_launcher then.

Perhaps I am missing some context about Melos and its usage of cli_launcher, which makes it hard to suggest a working fix for this task.

I think that we need to also pass in the settings to melos itself too, cli_launcher is just used to get the correct version of Melos, and then melos will run things itself (which might also include pub gets).

[blaugold]

Hey @foxanna I'm the maintainer of cli_launcher. 👋 I can add LocalLaunchConfig.skipPubGet. Would that help?

[foxanna]

Hi @blaugold! 👋🏻 Not sure, since @spydon mentioned melos may also be running pub get operation on its own.

[spydon]

@blaugold it would help! We'll just have to do it inside Melos too.