Technology/Tool: Moon, Proto & Moonbase

[alexanderniebuhr]

Background

For developers, ensuring consistent versions and streamlined setup of all necessary tools is paramount. Yet, the requirement for separate installations of certain tools—ones not manageable via a standard package manager—can obstruct this goal. This should never be the case in an effective tooling framework. Our aim is to facilitate a tooling system that is opt-in and universally compatible across all operating systems.

Proposal

We propose the integration of Moon (https://moonrepo.dev/moon), Proto (https://moonrepo.dev/proto), and Moonbase (https://moonrepo.dev/moonbase) for monorepository management, developer environment setup, and CI/CD caching, respectively. This recommendation applies to organizational projects and those community projects we onboard. Standalone projects, given their autonomous nature, are exempt from this suggestion, as their individual tooling setups suffice.

Moon, Proto, and Moonbase offer streamlined solutions that align with our vision. We advocate for their inclusion within project repositories on an opt-in basis. This ensures that even users with merely an installed Node version and corepack can engage with our projects, leveraging the correct package manager without coercion. While acknowledging the merits of other tooling options available in the ecosystem, we believe that they do not fully resonate with our long-term objectives.

In support of this proposal, we commit to providing comprehensive documentation and guidelines, incorporating these tools across all Astrolicious templates to encourage adoption and facilitate ease of use.

Advantages

• Performance: Exceptional efficiency and speed.
• Reliability: Proven stability and dependability in various scenarios.
• Unity: A single, cohesive tooling framework to cover a wide range of needs.
• Integration: Seamless compatibility with CI/CD pipelines, enhancing workflow continuity.

Disadvantages

• Recognition: Lower awareness within the developer community compared to more established tools.
• Completeness: Currently lacking certain features identified on our roadmap, which may necessitate temporary alternatives.

Conclusion

In evaluating the merits and drawbacks, we firmly believe the advantages of adopting Moon, Proto, and Moonbase significantly outweigh any current limitations. We trust in the continuous improvement and expansion of these tools, bolstered by adequate existing support. Nonetheless, we acknowledge the potential need to temporarily supplement our tooling suite to address any functionalities not yet available.

By embracing these innovative solutions, we take a step forward in refining our development ecosystem, ensuring it remains robust, efficient, and forward-thinking.

[florian-lefebvre]

Although those tools look awesome, I'm actually against using them in every project. I'm sure they make sense for some big monorepos (like integrated projects in this org) but that sounds overkill for many projects. I'm afraid it would scare first time contributors. I think we could have 2 setups depending on the project complexity:

1. Pretty simple (eg. an independent project in the org), using pnpm (through corepack). It only requires from contributors a minimum node version and a command to enable corepack. From there, we just need to specify the packageManager field in the root
2. More complex (eg. an monorepo of integrated projects in the org), using the tools you suggested. Looking at the official astro repo, turborepo is great because it doesn't get in the way of contributors. I don't know enough about moonbase to judge

[alexanderniebuhr]

Thank you for that perspective!

I totally agree with you, tooling should not get in the way for developers, but it should still be available for developers who want to use it.

I took your ideas to shape the following idea (also updated the initial description).
I would propose to include those tools in all organizational & onboarded community projects, but keeping them opt-in. They can be used if wished, but developers can still use just node and their package manager, if desired.
Standalone projects will always have their own rules, so that doesn't apply to them, at all.

Wdyt? Does that make sense to you?

[florian-lefebvre]

Yes I think that's great! We can offer developers help to migrate to this tooling setup and let them keep their existing one if they want! That sounds good