Allow integration with melos about mono_repo.dart HOT 7 OPEN

@natebosch Yes, #382 would be sufficient.

from mono_repo.dart.

I support better integration in principle. Figuring out the details is always fun, though.

CC @natebosch and @jakemac53

from mono_repo.dart.

Personally I would suggest just creating your own script under tool, which invokes melos and then mono_repo?

If we did want to support something like this I would probably just support running arbitrary commands, we don't want to be picking up a dependency on the api of melos.

from mono_repo.dart.

we don't want to be picking up a dependency on the api of melos.

+1

would #382 be sufficient to solve this use case?

from mono_repo.dart.

I'm not very familiar with mono_repo so I've created an example repo to better understand how to integrate it with Melos.

It's possible to get it working with Melos, but it's not great:

# a/mono_pkg.yaml
sdk:
  - stable

stages:
  - analyze:
      - command:
          - 'dart pub global activate melos'
          - 'dart pub global run melos bootstrap --scope a'
          - 'dart analyze'
  - format:
      - command:
          - 'dart pub global activate melos'
          - 'dart pub global run melos bootstrap --scope a'
          - 'dart format --output=none --set-exit-if-changed .'
  - test:
      - command:
          - 'dart pub global activate melos'
          - 'dart pub global run melos bootstrap --scope a'
          - 'dart test'

I don't think #382 would help all that much, since you would have to configure Melos for every job, if I understand the intent of the PR correctly.

It would be optimal, if there was a way to replace the pub upgrade step with an arbitrary command. Even better, if the command gets the name of the current package in an environment variable.

If this was configurable in mono_repo.yaml for all jobs, it would make it really simple to set up Melos.

from mono_repo.dart.

Yeah, having some template silly (like #382 ) would be nice. Not sure how much complexity we'd be adding...

from mono_repo.dart.

Would it make sense to expose TaskType.beforeAllSteps/TaskType.afterEachSteps, maybe via mono_repo.yaml, similar to how on_completion is exposed? My use case could also benefit from the lack of repetition. Another option would be to define a custom action in the repo and use #382, but that would lead to nearly the same amount of repetition, I think.

from mono_repo.dart.