Bazel inspired target patterns

[burdiyan]

Overall I really like Moon, but coming from many years of using Bazel and its cousins, I really got used to using file paths in target patterns instead of project names (or scopes) as in Moon. I really wish there was an easy way to invoke tasks based on the folder structure of the repo instead of an additional nomenclature of projects/scope that moon imposes.

Imagine a directory structure like this, where each of those folders has its own moon.yml file:

frontend
    packages
        auth-client
        editor
    apps
        desktop
        web
backend
    services
        auth
        users
        payments
    lib
        codegen
        utils
        db

With moon I have 2 options for targeting tasks in those projects:

1. Manual mapping of scope names to project paths.
   • This in practice lets me use slashes in scope names, so in theory I could mirror the folder structure and make it a scope name.
   • The downside is that this mapping has to be maintained manually.
2. Glob patterns.
   • Only the name of the leaf directory becomes the name of the scope, which can cause name clashes if folders have the same name.
   • Looses the context of the parent folders. Even if the leaf folder name is unique, it may be ambiguous or unclear in the global repository context.

None of these options are flexible enough to let me invoke tasks in arbitrary subtrees of the repo, so there's an additional concept in moon such as tags and layers, which I could bolt on to have more flexibility, e.g. to invoke #frontend:build task on all the frontend packages.

In summary, my point is that the repo already has some defined structure which developers are familiar with — folders, which moon doesn't really take advantage of, forcing you to either replicate this structure with additional concepts, or coming up with a separate structure, which is unclear for someone who's just starting with moon.

In Bazel and its cousins (Buck2, Pants, Please, etc.) things are much easier. What's scope in moon is called label in Bazel, and it's very flexible. Translating this idea to moon it could look something like this:

• moon run //backend/...:build — run build task on all the descendant packages under backend directory.
• moon run :update-deps (or //:update-deps) — run update-deps task in the root of the repo, provided it has its own moon.yml. Currently in moon this would run the task in all the projects.
• moon run //frontend/packages/auth-client:test //frontend/apps/...:test — run test target, combining explicit project name and wildcard in disjoint subtrees.

You can see more examples of target patterns in Bazel docs.

I don't know if something like this could be added to moon at any point, and whether you'd be interested in that, but this one thing starts being kind of a deal-breaker for me. I'm not saying moon should implement exactly the way Bazel does it, but I think it would be really helpful if moon would be able to take advantage of the existing structure of the repository at least as an option.

For example, maybe when defining globs in the moon workspace, there could be an optional flag to make it use entire paths as scope names instead of just the name of the leaf directory?

[milesj]

I've actually thought about this a bit, as I've used bazel quite a bit in the past. I agree, using the dir name only is not the best solution, as the chance of conflicts is very high. I was thinking about something like this:

projects:
  globs: [...]
  globNamePattern: 'dir-path' # file-name, some others?

This would result in project IDs using the dir path, relative from the workspace root, so something like moon run packages/common/components:build.

As for the ... filtering syntax. I'm unsure about this. I'm currently leaning to just using CLI args + query language stuff to achieve it.

[burdiyan]

This would result in project IDs using the dir path, relative from the workspace root, so something like moon run packages/common/components:build.

Right! I guess this is similar to what I mentioned in the last point:

For example, maybe when defining globs in the moon workspace, there could be an optional flag to make it use entire paths as scope names instead of just the name of the leaf directory?

One annoying problem with paths that will immediately come up is when projects need to depend on other projects in some other subtrees. It's tempting to use relative paths, which are very hard to debug and refactor, and this is where I believe Bazel's leading double-slash pattern really shines. It's much easier to refactor with just "search and replace" for full path patterns. I know in JavaScript ecosystem it's common to use the @, or ~ signs for meaning "home of the workspace" to solve a similar problem. Without having a way to reference root of the workspace in any way I feel like using paths could lead to even more mess than hard-coded project names. That is unless when dir-path glob name pattern is used you must use full workspace-relative path all the time I guess.

As for the ... filtering syntax. I'm unsure about this. I'm currently leaning to just using CLI args + query language stuff to achieve it.

Fair point. With some sub-shell magic for querying relevant targets which can then be passed to moon run one should get enough flexibility for whatever they want to do.