Replace multipack with melos

[klavs]

Drop multipack in favor of melos.

Publishing should be improved later, but since it's not contributor-facing, it can stay for a bit.

Jobs to migrate:

• packages
• examples
• builder_tests
• publish_dry_run
• check_svg
• publish

[Salakar]

--scope="foobar" I think btw, no space plus equals sign

[klavs]

Half way there.

check_svg requires invertase/melos#58 to be merged and published

still need to investigate how melos can help with publishing scripts

[Salakar]

check_svg requires invertase/melos#58 to be merged and published

0.4.5 published with the PR merged, thanks for the PR :)

[Salakar]

still need to investigate how melos can help with publishing scripts

If you're not automating this with conventional commits then maybe melos version <packageName> <newVersion> would be helpful instead, it can version bump your pubspec, update version constraints of other packages in your workspace that depend on it, create a change log entry (command prompts for input and create a git tag - all of these can be toggled off also via flags on the command. And then melos publish after (dry run by default) will help you publish any unpublished package versions in your workspace.

[klavs]

Thanks @Salakar for your help. I'll continue tomorrow.

[klavs]

Actually let's keep multipack publishing scripts for now. Maybe it's worth improving the process instead of trying to get the old process from a new tool.

[klavs]

@agent3bood @agent3bood @smkhalsa

It would be nice to hear your opinion about using melos. I think it is not viable to keep maintaining multipack.

[smkhalsa]

@klavs apologies for not getting to this yet. I've been very busy lately.

I'm definitely supportive of the effort to consolidate the projects.

I'll try to give melos a go in the next day or two.

[agent3bood]

I am try to make this work, first we have to activate melos and run melos bootstrap; now how to I run test against specific package?

[Salakar]

I am try to make this work, first we have to activate melos and run melos bootstrap; now how to I run test against specific package?

@agent3bood

There's a ton of package filtering options (melos run --help) that you can use in combination with melos exec, e.g. melos exec --scope=some_package -- dart pub run test ...

Repositories such as this one can also predefine all sorts of scripts in the repositories melos.yaml file: e.g.

# ...

scripts:
  analyze:
    run: melos exec -c 1 -- "dart analyze . --fatal-infos"
    description: Run dart analyzer in a specific package.
    select-package:
      ignore:
        - "*monorepo*"

  test:
    description: Run tests in a specific package.
    run: melos exec -c 1 -- "dart pub run test test/\$MELOS_PACKAGE_NAME_test.dart"
    select-package:
      file-exists:
        - "test/$MELOS_PACKAGE_NAME_test.dart"

With those defined in the melos.yaml, anyone cloning the project can now run the analyze or test scripts easily in various ways which even include prompting to select a package:

# Option A) To prompt to select from the available scripts.
melos run

# Option B) Run a specific script by name, e.g. the 'test' script defined above:
melos run test

With the above script definitions optionally including the select-package definition the script will prompt to select a package to run it against (with baked in filters) when ran, e.g.:

On CI environments or when --no-select is passed to the run command then selection prompting is disabled and defaults to all packages that match the pre-defined filters in select-package.

melos run without specifying a script name will prompt to select a script along with showing the defined script descriptions:

---

If you want to try out or look at some repositories that have predefined scripts check out:

• https://github.com/invertase/melos
• https://github.com/FirebaseExtended/flutterfire

---

TLDR; this project could add some common used scripts in it's melos.yaml definition to help with running common local development tasks.

[klavs]

Thank you very much @Salakar! I think it's a good idea to move scripts to melos.yaml so that the useful stuff is not hidden in the CI scripts.

[micimize]

LGTM – spot checked some CI output and didn't find any false positives.

Moving workflows into melos.yaml is a good idea but IMO we should call melos run test etc to maintain granularity in github action view

[klavs]

I'll make some adjustments to get rid of uni as well.

[smkhalsa]

@klavs is this ready to go?

[smkhalsa]

I just revamped ferry's github workflows to use melos for publishing to pub.dev, and I'm prepared to pick this issue up while it's fresh in my mind.

However, for melos to be able to automatically version and generate changelogs, we'd need to either:

1. Enforce conventional commits everywhere going forward, OR
2. Use "Squash and Merge" when merging to squash commits using a conventional commit message

Option 1 seems less tedious and confusing, especially for PRs from external contributors.

I can include a github action to enforce conventional PRs. By default, when there are two or more commits in a PR, github uses the PR name as the squashed commit message, so enforcing conventional PRs will make it easier some of the time (but we'd still need to remember to use conventional commit messages when squashing and merging a single commit PR).

@agent3bood @TarekkMA thoughts?

@Salakar any further suggestions on how best to enforce conventional commits?

[Salakar]

@Salakar any further suggestions on how best to enforce conventional commits?

We use a combination of 1 & 2 - but we also allow Rebase alongside Squash Merge - allows multiple commits for those that do them correctly (each being conventional) to get merged 'as is' whilst also allowing Squashing for those that don't. For 1 we don't actually enforce the commits but rather the PR title (see https://github.com/FirebaseExtended/flutterfire/blob/master/.github/workflows/pr_title.yaml) - since this title get's used by GitHub as the commit message default when you start PR merge. However with this approach it's still up to the PR merger to ensure everything is in order.

You can also break the release process up on Melos if you want to add an additional review of changelogs before releasing since you don't have to have change logs and versions tagged and committed immediately for a release with Melos; we're probably going to change FlutterFire to something like the following flow sometime:

• Manual trigger GH action to start a release, which does:
  • Clone repo and git fetch --all (to ensure all tags are fetched)
  • Create a new branch
  • melos version --no-git-tag-version
  • Commit changelog and pubspec files - since --no-git-tag-version flag stops this happening automatically as well as it skipping creating git tags
  • push & automatically create a PR for review
• Maintainers can now review and make changes to the release PR
• Automatic GH action to publish the packages that triggers on commit to main branch with a certain key word in the commit description (e.g. [release]), so when the release PR merges, which does the following:
  • Clone repo main branch
  • melos publish --dry-run - to ensure all working (could be done on the PR before merge instead)
  • melos publish --no-dry-run --git-tag-version (this flag will create the git tags that were skipped in manual melos version)
  • git push --follow-tags - to push up newly created tags

I would note it doesn't have to be a manual trigger for starting the release process - it's just something we want to do so we can release when we want to, e.g. collate non-critical changes into a larger release.

[2shrestha22]

What is the status here? multipack is outdated and not working with latest dart SDK.