Merge package:source_gen

[mosuem]

• Move and fix workflow files, labeler.yaml, and badges in the README.md
• Rev the version of the package, so that pub.dev points to the correct site
• Add a line to the changelog:

* Move to `dart-lang/build` monorepo.

• Add the package to the top-level readme of the monorepo:

| [source_gen](source_gen/source_gen/) |  | [![package issues](https://img.shields.io/badge/package:source_gen-4774bc)](https://github.com/dart-lang/tools/issues?q=is%3Aissue+is%3Aopen+label%3Apackage%3Asource_gen) | [![pub package](https://img.shields.io/pub/v/source_gen.svg)](https://pub.dev/packages/source_gen) |

• Important! Merge the PR with 'Create a merge commit' (enabling then disabling the Allow merge commits admin setting)
• Update the auto-publishing settings on https://pub.dev/packages/source_gen/admin
• Add the following text to https://github.com/dart-lang/source_gen/:'

> [!IMPORTANT]  
> This repo has moved to https://github.com/dart-lang/build/tree/master/source_gen/source_gen

• Publish using the autopublish workflow
• Push tags to GitHub using

git tag --list 'source_gen*' | xargs git push origin

• Close open PRs in dart-lang/source_gen with the following message:

Closing as the [dart-lang/source_gen](https://github.com/dart-lang/source_gen) repository is merged into the [dart-lang/build](https://github.com/dart-lang/build) monorepo. Please re-open this PR there!

• Transfer issues by running

dart run pkgs/repo_manage/bin/report.dart transfer-issues --source-repo dart-lang/source_gen --target-repo dart-lang/build --add-label package:source_gen --apply-changes

• Archive https://github.com/dart-lang/source_gen/

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[github-actions]

PR Health

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

[jakemac53]

This script can be deleted, it was a part of the old CI setup

[kevmoo]

Suggested change

	.dart_tool
	.packages
	.pub
	packages
	pubspec.lock
	.dart_tool
	pubspec.lock

This can be cleaner 😄

[kevmoo]

I know it's a bit ugly, but I really like the mono_repo-ness of source_gen. It makes it MUCH easier to explain how to use it

I think I'd argue this doesn't make sense to merge as a mono-repo.

[natebosch]

It makes it MUCH easier to explain how to use it

What aspect is more difficult with the code here? We can still have a standalone example for source_gen, it's just 1 directory lower than it was in the old repo.

[kevmoo]

@natebosch – nested packages give me a headache.

[jakemac53]

From the other perspective, what do we actually gain by merging this into the mono repo? This has never been clear to me.

Here are the downsides from my perspective:

• Cannot watch only issues pertaining to source_gen (or the opposite, people who care about build but not source_gen can't only watch the build related issues).
• More complexity around GitHub actions, and it's wasteful in terms of CI resources as currently set up.
• More steps to set up a "clean" workspace in VsCode (opening up just the root of the build or source_gen repos was quite reasonable before, now there is going to be more there, and most of it isn't relevant to a given task).
• Larger issue counts, larger PR counts, which are difficult to manage. I think having separate repos is much nicer in this regard. Labels are not really equivalent.
• Can't really use pub workspaces, they don't really work well with unrelated packages.

[mosuem]

From the other perspective, what do we actually gain by merging this into the mono repo? This has never been clear to me.

Here are the downsides from my perspective:

• Cannot watch only issues pertaining to source_gen (or the opposite, people who care about build but not source_gen can't only watch the build related issues).

This is indeed a downside for users of single packages. From a team and maintenance perspective on the other hand, we saw many issues and PRs fall through the cracks as people didn't follow some repositories. Seeing all issues and PRs in one place makes this simpler. We have tried to ease this in other repos by providing links to filtered lists, see the https://github.com/dart-lang/tools/ readme.

• More complexity around GitHub actions, and it's wasteful in terms of CI resources as currently set up.

I don't think the CI is wasteful - through path restrictions, CI should only run for the changed packages. Also, we use very little CI capacity across the dart-lang org. The CI setup also becomes simpler IMO, as we don't have to update and maintain CI scripts across different repositories, for example the PR health workflow.

• More steps to set up a "clean" workspace in VsCode (opening up just the root of the build or source_gen repos was quite reasonable before, now there is going to be more there, and most of it isn't relevant to a given task).

I agree with this, I don't know if this is a big issue in practice. We could add some documentation on https://git-scm.com/docs/git-sparse-checkout to help a bit.

• Larger issue counts, larger PR counts, which are difficult to manage. I think having separate repos is much nicer in this regard. Labels are not really equivalent.

I agree with this problem in principle, but don't think this makes it much harder to manage.

• Can't really use pub workspaces, they don't really work well with unrelated packages.

You can use multiple pub workspaces if needed, as is happening here.

We should probably discuss this elsewhere, such as dart-lang/sdk#56591, or do you mean those points only in regard to this merge in particular? FWIW, I think monorepos make everything easier and am a big fan, if it were up to me we would have only one repository for all packages ;)

[kevmoo]

I'd rather have a seperate pub workspace then. Although, honestly, I'd strongly vote to just leave this stand-alone.

[jakemac53]

From a team and maintenance perspective on the other hand, we saw many issues and PRs fall through the cracks as people didn't follow some repositories.

This issue is imo purely an issue of ownership and process. The packages simply don't have owners, and have been maintained on basically a volunteer basis. We could also fix it with tooling if we wanted it to be simpler to follow groups of packages. There is a fixed one time cost to following a repo.... and it's a single click of a button...

The unrelated packages mono_repo approach risks having the opposite effect of causing people to stop watching whole groups of packages due to spam that they can't filter out.

We have tried to ease this in other repos by providing links to filtered lists, see the https://github.com/dart-lang/tools/ readme.

This just shows you all the issues, not the issues needing your attention, which is the key feature of notifications. And they aren't all in one place either. It is useful if you want to look over issues to find one to work on but that is about it?

I don't think the CI is wasteful - through path restrictions, CI should only run for the changed packages. Also, we use very little CI capacity across the dart-lang org. The CI setup also becomes simpler IMO, as we don't have to update and maintain CI scripts across different repositories, for example the PR health workflow.

I understand it can be restricted by path but it isn't in this case, because mono_repo doesn't support that. Concretely in this case the CI turnaround time is likely much longer than it was previously for source_gen, because it will be running all the package:build tests.

I agree with this, I don't know if this is a big issue in practice. We could add some documentation on https://git-scm.com/docs/git-sparse-checkout to help a bit.

There are of course workarounds but this is all ultimately adding extra complexity. I can also just create a custom workspace that has fewer directories open (like I do for the Dart SDK).

We should probably discuss this elsewhere, such as dart-lang/sdk#56591, or do you mean those points only in regard to this merge in particular? FWIW, I think monorepos make everything easier and am a big fan, if it were up to me we would have only one repository for all packages ;)

My issue is that I keep hearing that it will make things easier but what I am not hearing is what they will make easier. I am only seeing the things that will make my daily tasks more difficult. What are the specific developer tasks that are made easier?