dart pub get - in all sub folders?

[dcharkes]

Should we consider letting dart pub get do a dart pub get in all folders that contain a pubspec.yaml?

For example, when one has a package with an example/ folder that contains a full package.
Or when opening a mono-repo with pkgs/.

I often find myself manually going to folders to do pub get.

Flutter already does this by default.
And so does Dart-Code the VSCode plugin.

(I believe this was discussed before, but I can't find a tracking bug.)

[sigurdm]

Good question

We have --example that also runs pub get in the example folder. I think we wanted to make that default at some point (to align with flutter pub get). @jonasfj should we try to land that change today that it would get into 3.0?

I think one might have pubspec.yaml files in subfolders for a number of reasons, so just blindly going through them all seems risky to me.

We have --directory/-C that can save you from going into the subfolder. Maybe we should make that a multi-value option, in that way one could do a single invocation for all the subfolders (but you would still have to list them explicitly somehow). That would save time, because we only would request version-listings once for shared dependencies.

Side-note: I believe mono-repo supports a command like monorepo pub get that runs pub get in all repo-folders.

[dcharkes]

@DanTup What is the logic in DartCode?

[DanTup]

In Dart-Code we walk down the open workspaces folders and collect the set of projects (where we find pubspec.yamls), prompt the user if something needs running and then run it sequentially each one we decided required it. I think in the case where the user invokes the "Get Packages" command directly, we will just run it for the project that contains their active file (or if we can't find one, prompt them to select a project from those we find in the workspace).

Worth noting that in VS Code you can have multiple folders in your workspace, so if you had:

my_project/
  a/
  b/
  c/

You could open a workspace that has my_project/a/ and my_project/c/ in it (so b/ is not in the workspace).

It could be useful if we only needed to run pub at the top of each workspace folder, although we'd probably still need to detect all the packages in some cases because at startup we're first checking to see whether we should prompt the user to run pub get because something is out-of-date. I'm also not sure whether your intention is to support running "pub get" in a non-project folder where projects are all in sub-folders (since the open folder in VS code might just be a container and not a project directly).

On a massive tangent...:

Something I often think about, is a general "tools service" that tools like Flutter, Pub, Dart, package:test could be available in. Right now there are a bunch of utilities that are just process invocations that don't match the way an editor works very well. I could imagine some "super service" that is long-running with the editor that can perform tasks like:

• tell me which projects may need pub get/pub upgrade running
• run pub get/pub upgrade for these projects
• give me a list of packages for code completion purposes
• tell me which (Flutter) devices are available
• tell me a list of test suites and tests in this workspace

Currently a lot of these tasks are spawning new processes and the editor has to manage them all, but in many cases that includes logic that might be better inside the tool itself (for example Dart-Code is checking timestamps on files like pubspec.lock and .dart_tool/package_config.json and making assumptions that it would be nicer if it didn't need to in case they change).

[sigurdm]

@dcharkes Does making --example be default fix this issue?

I think pub going through all subfolders for pubspec.yamls is a bit much... should probably be handled by a wrapping script (such as mono-repo) if you have a lot of related packages to update...

[dcharkes]

I have lost context of what workflow I had when I was filing this issue. (And I'm mostly work from VS Code with Dart Code where I can rely on it's behavior, so it must have been a workflow where I was not in VS Code.)

Maybe we should not optimize for my specific workflow in a specific point in time. So far my issue only has one upvote, so maybe not many people are running into this.

[sigurdm]

Ok, will close as no-action for now. Please reopen/open a new issue if we should consider doing more.

[dcharkes]

dart pub publish --dry-run implicitly runs a dart pub get in the main folder, and subsequently ignores analysis_options.yaml excludes, causing dart-lang/ecosystem#150.

dart pub publish --dry-run listening to analysis_options.yaml would enable me to publish a package version. However, I'd rather not ignore my test/data/ full Dart projects. Rather, pub get should be run in all subfolders with a pubspec.yaml.

[sigurdm]

and subsequently ignores analysis_options.yaml excludes.

I'm actually surprised by this. I think we just invoke dart analyze lib test pubspec.yaml. I would have guessed that it should pick up excludes...