🛣️ Roadmap & backlog

[milesj]

In no specific order.

Completed

• Host your own remote cache, powered by Bazel remote APIs
• Task graph
• Terminal notifications
• Run tasks without the action graph (no actions besides RunTask)
• Migrate toolchain to a WASM plugin based architecture
• Daemon

In progress

Must haves

• Rust optimizations / performance
• Manage system packages/dependencies within the toolchain
• Task watcher (moon watch equivalent to moon run)
• Release workflows (build -> package -> publish)
• Setup tasks that run when setting up the workspace
• Cleanup tasks that run after a task that fails or passes
• Project & code ownership improvements
• Repository & project health scores
• New token system
• New source groups feature (replaces file groups)

Nice to have

• Different CLI reporters (terminal output)
• Interactive TUI
• Repository lint rules
• Secrets management
• Artifact signing for remote cache
• Deeply integrated dependency management
• Dependency alignment / enforcement across projects
• Enforce a single version policy for dependencies
• Other VCS integrations (svn? mercurial?)
• Update moon sync to target specific plugins
• moon specific ignore file/rules
• Apply 12 factor methodology to our tools
• Vulnerability detection / information gathering

2.0

• Toolchain WASM plugins
• Move bun/node/deno shared functionality into a new javascript toolchain
• Migrate to cargo-dist for binary distribution
• Rename vcs.manager to vcs.client
• Rename codeowners.syncOnRun to codeowners.sync
• Rename runner to pipeline
• Rename "touched" to "changed"
• Convert CLI options/args/etc to kebab-case
• Remove moon dep-graph (use action-graph instead)
• Improved task inheritance
• PGO binaries: https://doc.rust-lang.org/beta/rustc/profile-guided-optimization.html
• Default project - moon run build would run from the default project

[jbadeau]

We currently have internally developed some of these things based on Nx:

• Release workflows
• Repository lint rules
• clean tasks

We would be happy to share what we have done.

One feature from Nx that has really reduced our support has been project crystal/inferred targets. We originally were not fans as it brings allot of magic but it has grown on us and now we would never go back to manually configured targets. Any plans for something like crystal?

[milesj]

One feature from Nx that has really reduced our support has been project crystal/inferred targets. We originally were not fans as it brings allot of magic but it has grown on us and now we would never go back to manually configured targets. Any plans for something like crystal?

I don't follow Nx so I'm not sure what this is. Have a link?

But I'm typically of the mindset of explicit is better.

[harlequin]

@milesj
I would like to see that "proto use" will be called on moon init phase, from the roadmap there are 2 points which would fit

• Manage system packages/dependencies within the toolchain
• Setup tasks that run when setting up the workspace

What do you think is the best place to put this?

[milesj]

@milesj

Manage system packages/dependencies within the toolchain

This one is very complex and requires finishing this crate: https://github.com/moonrepo/proto/tree/master/crates/system-env

I'll probably have to tackle this one.

Setup tasks that run when setting up the workspace

This one is a bit easier. It would be configured in .moon/workspace.yml and ran during the SyncWorkspace action. However, it shouldn't run everytime, and should be cached/hashed like everything else.

[harlequin]

Setup tasks for workspace would be an excellent feature.

90% of the "system tools", which I am using, can be installed via proto.

So with the capability to call proto use in combination of auto install setting would be absolutely sufficient.
Or the end user can even call specific tasks for installing proto tools, like proto install dotnet.

[milesj]

Yeah definitely. Let's focus on landing the python PR, then we can discuss these setup tasks.

[muandane]

We currently have internally developed some of these things based on Nx:

• Release workflows
• Repository lint rules
• clean tasks

We would be happy to share what we have done.

One feature from Nx that has really reduced our support has been project crystal/inferred targets. We originally were not fans as it brings allot of magic but it has grown on us and now we would never go back to manually configured targets. Any plans for something like crystal?

i would really like to see the release workflows using moon

[plumj-am]

+1 for release workflows, it sounds awesome :]

[Tim-Hodge]

Are there any plans to extend the moon run --query capabilities to work with project metadata? At the moment I don't believe it's available here.

For example I have a number of moon.yml similar to:

project:
  description:  "Another IaC project"
  metadata:
    stacks:
      - env: "prod"
         other: "stuff"
      - env: ...

And would like to do moon run --affected --query "projectMetadata~env: prod" :up (or something to that effect).

A current workaround is to also add the info as tags, but it feels like a duplication and isn't as expressive.

[milesj]

There are plans to rework all the query stuff, but it's on the backlog.

[Binlogo]

VSC integration: Git sparse-checkout "auto"-management based on projects&tasks graph?

I'm not sure if this is the best place to discuss this feature proposal. Apologies in advance.

There's an unmaintained project called focus that aligns Git worktree content (git-sparse-checkout) based on a repository's Bazel build graph.

If a moon workspace, which is aware of the projects-graph and tasks-graph, integrates the "focusing" feature into Git VSC, it could significantly enhance performance in large repositories.

Why does Git sparse-checkout matter?

When executing a moon task, it uses the following Git command to determine whether to use the cache: git ls-files --full-name --cached --modified --others --exclude-standard and git hash-object.

In a large repository, this operation can be quite slow, potentially taking more time than the task itself.

If graph-aware Git sparse-checkout support is available, this problem may be alleviated.

[jbadeau]

Have a look at https://blog.ordina-jworks.io/architecture/2020/03/31/nx-sparse-checkout.html for some inspiration

[sarendipitee]

Now that Daemon mode is out... any news/thoughts on Task watcher (moon watch equivalent to moon run)?

I can see this being super handy actually.

Say you have a terminal multiplexer running several moon run *:start commands. Each of these would thrash moon with several parallel invocations. A workaround would be to have one pane be moon watch that automatically rebuilds dirty projects.