🛣️ Roadmap & backlog

[milesj]

In no specific order.

In progress

• Migrate toolchain to a WASM plugin based architecture
• Host your own remote cache, powered by Bazel remote APIs
• Task graph

Must haves

• Rust optimizations / performance
• Daemon
• 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
• Terminal notifications

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

[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.