Cascade pub get to parent project in multi-project setups

Is your feature request related to a problem? Please describe.
I regularly work in Flutter with multi-root projects for enforced clean architecture. This is great to assert separation of concerns at package level.

presentation layer does no see the data layer, it must access data through the domain layer
domain layer does not see the data layer, it must receive implementation injections of its interfaces
and so on...

This works beautifully the only downside is that when I add a package to a layer pubspec.yaml, say the _presentation layer, Dart extension will run pub get for me and I can continue coding... but when the app reloads that lib won't be delivered to my device unless I also run pub get on the main project yaml.

Describe the solution you'd like
Thus I would like to have an option in this Dart extension to run pub get on the parent project whenever it is run on sub packages.

Describe alternatives you've considered
I sometimes turn off automatic pub get on pubspec changes, and use a command line script that runs pub get on the current package and on the main project.... This works but is not that convenient.

Additional context
The structure I use is available as a template in https://github.com/cc-nogueira/flutter_layered_template, and it uses the common multi-package structure under the packages folder, each one defined as a root folder for VSCode.

main project
- lib/main.dart
- packages/
  - coreLayer/*
  - dataLayer/*
  - domainLayer/*
  - presentationLayer/*
  - servicesLayer/*
  - diLayer/* (dependency injection layer that see all layers and configures them at app initialization)

King rasgards,

Ricardo

If I understand correctly, I think this is the same issue described in #3974.

The extension only walks 3 levels deep looking for projects for performance reasons. You can increase this with the dart.projectSearchDepth setting, but it may result in some operations (including startup) taking a little longer if you have a large folder open.

There's a suggestion in that issue to show a progress indicator while searching so that it's easy to cancel, which might be a reasonable trade-off to allow the default to be increased.

Not really the same issue... #3974 is about building a project with nested libs and examples.

I wish the Dart extension would search UP the directory structure for a single parent project (two directories up) that would have in its pubspec.yaml a dependency to this changed package.

I mean I am changing dependencies in a sub-package and there may be a parent package that depends on it.
This parent package would have a entry like this in its pubspec.yaml:

dependencies:
  subpackage:
    path: ./packages/subpackage

When I update or add a dependency to a subpackage I have to run pub get there and then go two directories up, to the main umbrella project, and run pub get there too.

I always develop apps with the aforementioned layered structure (each layer in a subpackge).
Hope to have made my point clear. Cheers!

@cc-nogueira

@cc-nogueira ah, thanks for clarifying!

@stevemessick

Thinking about this more, I don't know if walking up the tree is the ideal solution. It seems like it would be possible to have this same issue without the project being nested:

workspace/project1
- references workspace/project2 via a path dependency in its pubspec.yaml
workspace/project2

If you modify the project2 pubspec.yaml here, it seems like you'd have the same problem - the newly-added dependency is not in the .dart_tool/package_config.json for project1. Making pub get work for parent folders only fixes the instance where the projects are nested but not where they're side-by-side like this.

I think a better fix could be for us to look in the package_confg.json files for each project in the workspace, and run pub get for any of them that reference the package we're already running pub get for.

@stevemessick @jacob314 does IntelliJ do anything to handle this? Can you think of a better way than the IDE reading .dart_tool/package_config.json to see if there are any packages depending on the current one?

I think #3974 is asking for support for monorepo projects, where multiple (possibly independent) projects reside under a common root and the root is opened in the IDE. This issue seems like it is asking for support for a different kind of project, where sub-projects are not independent. I have some thoughts on monorepo projects, since I've been trying to schedule it for the IntelliJ plugin, but this structure is new to me.

For monorepo projects, my thinking for the IntelliJ plugin is to do something similar to what the Dart plugin does. It defines an IntelliJ module for each sub-project. The plugin settings page allows each module to be supported or ignored by the Dart plugin. I'd like to add something similar for the Flutter plugin. Then, when flutter pub get is run at the top-level, it runs the command for every supported sub-project. If the command is run on a sub-project then it only updates the selected one. And similarly for other commands.

In my view, trying to support all possible project structures makes the code too complex. In this case, configuring the search depth seems like a good solution, with the possible addition of a progress indicator. The changes I'd like to make to the IntelliJ plugin would also work for this project, I think. I'm not familiar enough with VS Code to know if it has anything like IntelliJ modules.

Since we already located the project roots and supported running pub get for multiple projects on pubspec change, I implemented a basic setting to support this. It's off by default, but you can set it to run pub get in all parent, children or both projects when a pubspec changes:

It does not attempt to figure out the relationships between projects using the pubspec, it's just a simple switch you can enable for projects where this relationship exists. It will run pub get sequentially (the same as if you opened a project folder and there were multiple projects whose package_config.jsons where out-of-date/missing.

I added support for both directions, since the request here was to go up, but it's also common to have an example folder nested, so going down could be useful too.

(and related to the other discussion above about project searching, #3974 was implemented.. we know search deeper for projects but also show a progress indicator if the search goes over 1s allowing the user to cancel it early and we'll use just the projects already discovered in that time).

Support running "pub get" in parent/child projects when pubspecs change

Navigation Menu

Repository navigation

Cascade pub get to parent project in multi-project setups #3990

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Cascade pub get to parent project in multi-project setups #3990

Description

Activity

DanTup commented on May 24, 2022

cc-nogueira commented on May 28, 2022

DanTup commented on May 30, 2022

DanTup commented on May 30, 2022

stevemessick commented on May 31, 2022

DanTup commented on Jun 30, 2022

DanTup commented on Jun 30, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions