Support server restarts using pub workspaces

[sigurdm]

Currently one has to manually restart build_runner on each pub get when using workspaces.

Context being discussed in #3717

[natebosch]

I think this is the main problem

build/build_runner_core/lib/src/generate/build_definition.dart

Lines 105 to 106 in b3d3ef1

	var packageConfigId = AssetId(_targetGraph.rootPackageConfig.packageName,
	'.dart_tool/package_config.json');

This is already broken for some non-standard setups if the file isn't at exactly the hardcoded path. We could fix this for unexpected paths under the root package, but as Jake mentioned this causes a problem when the package config is outside of any package.

My first hacky idea is to add a synthetic package for this, I think we discover the package config when building the package graph so we should have the information we need. We'll also need to communicate that path through to the above lines, so we probably need to add it as another field on both PackageGraph and TargetGraph.

[jakemac53]

True, we could go the synthetic package route similar to how we handle SDK sources. Not sure what we want to call it, $workspace?

[natebosch]

Hmm, build_runner doesn't work at all for packages using pub workspaces.

build/build_runner_core/lib/src/package_graph/package_graph.dart

Lines 221 to 227 in 039aeca

	Map<String, DependencyType> _parseDependencyTypes(String rootPackagePath) {
	final pubspecLock = File(p.join(rootPackagePath, 'pubspec.lock'));
	if (!pubspecLock.existsSync()) {
	throw StateError(
	'Unable to generate package graph, no `pubspec.lock` found. '
	'This program must be ran from the root directory of your package.');
	}

I'm not sure how we wouldn't have hit this earlier though...

[natebosch]

Hmm, build_runner doesn't work at all for packages using pub workspaces.

This was a local issue, I still had some .packages files tripping things up.

[sigurdm]

I think this is done.

[sigurdm]

Sorry - I misread what this issue was about. We probably still should do this.

[SalihCanBinboga]

.
├── app
│   ├── analysis_options.yaml
│   └── pubspec.yaml
├── modules
│   ├── common
│   │   ├── location_manager
│   │   │   ├── analysis_options.yaml
│   │   │   ├── index_generator.yaml
│   │   │   └── pubspec.yaml
│   │   └── ui
│   │   ├── analysis_options.yaml
│   │   ├── index_generator.yaml
│   │   └── pubspec.yaml
│   ├── core
│   │   ├── index_generator.yaml
│   │   └── pubspec.yaml
│   └── features
│   ├── back_office
│   │   ├── back_office_create_meeting
│   │   │   ├── analysis_options.yaml
│   │   │   ├── index_generator.yaml
│   │   │   └── pubspec.yaml
│   ├── client
│   │   ├── client_announcements
│   │   │   ├── analysis_options.yaml
│   │   │   ├── index_generator.yaml
│   │   │   └── pubspec.yaml
└── pubspec.yaml

Hi, everything under the app and modules directories is set to resolution: workspace. When I run dart run build_runner build at the root directory, the annotations within the workspace are not being generated. I have to navigate to the respective workspace and run dart run build_runner build there. Is this not supported? @sigurdm @natebosch

[jakemac53]

Yes, this is not supported. You still have to run build_runner on each package individually.

[sigurdm]

Yes, this is not supported. You still have to run build_runner on each package individually.

Do we want to support this? How would it look?

[SalihCanBinboga]

Do we want to support this? How would it look?

My build_runner process takes 10-15 minutes to complete for my project. There are too many workspaces, and running it for each one individually is very costly. I think it would be great..

[jakemac53]

I have certainly thought about supporting it, but it would require a fair bit of redesign work. There is currently an assumption that there is only one "root" package. That package is treated specially in a few ways, and it isn't clear what it would mean to remove that. Specifically:

• Build to source builders only run on the root package
• The root package anchors the ordering of the build, it isn't clear how ordering should work in a workspace setting (although we could just choose an arbitrary order).
• The root package has all its sources available, instead of only its "public" sources (those under lib by default).

[jakemac53]

It isn't clear that we would get a performance win from this either (could be worse actually).