Better ergonomics for scripts

Hello!

I’ve been using your project to manage about 150 repos and I’ve been loving it. I’ve had a few pain points, but one is that many of my meta exec statements only apply to a few repositories. For example, I’ll do something like this:

script.sh

if ! [ -a .meta ]; then
  BRANCH=$(git remote show origin | grep "HEAD branch" | sed "s/.*: //")
  git fetch origin
  git checkout $BRANCH
  git reset --hard origin/$BRANCH
  git clean -fdx
  if [ -a package.json ] && ! [ -a .gitignore ]; then
    echo 'node_modules' > .gitignore
    git add .gitignore
    git commit -S -m 'Add .gitignore to ignore node_modules'
    git push origin $BRANCH
  fi
fi

meta exec "$(< script.sh)"

Here are my pain points:

• I’ll often want to exclude the meta repo, and this seems better suited to a CLI flag than if ! [ -a .meta ]
• I only want to run commands on repos with package.json, but I get output from all repos – it would be great if repos without any stdout just didn’t show up at all
• I personally don’t mind the shell command above, but meta exec -f script.sh might be more ergonomic

Thanks for your work on this project, I’m loving it!

[patrickleet]

I have meta repos of meta repos, which may or may not make sense for your project, but keep in mind you can slice and dice things different ways and even for different use cases. The same project can exist in many meta repos.

You could make a meta repo called ‘node-projects’ and then run those maintenance type commands from there.

Lately, I’ve been using a meta repo per bounded context, which maps to a deploy to a single helm chart that describes that context and the versions of each of their services.

[mateodelnorte]

I’ve built some of this into the plugins, themselves. meta-loop allows you to pass an options object with a test property which accepts a function that returns a boolean. If that boolean is true, meta-exec will run on the current dir. Else, it will skip.

https://github.com/mateodelnorte/meta-npm/blob/master/bin/meta-npm-install#L13

@patrickleet has talked about having keys or groups of projects, which could be referred to in commands. I think that’s not a bad idea, but I’d also like to watch out for cluttering up commands as much of the power of these tools is just how simple they are.