Replies: 1 comment 2 replies
-
@mattmast Thanks for your concern, but let me clarify a few things around plugins that'll hopefully ease your mind. To start, moon plugins are nothing like Nx plugins. Nx plugins are more like wrappers around specific tools to automate tasks/configs, and are either authored by the Nx team themselves, or by the community. Nx kind of forces you to use plugins, which we agree, is not a nice abstraction. moon plugins are more of an internal only thing, and are split into 2 categories right now: extensions and platforms.
Both of these plugins should be entirely transparent to consumers and will just automatically work behind the scenes. Furthermore, consumers don't really need to know about them, or write them themselves, they kind of just exist. However, we call them plugins because if a consumer does want to build and use their own plugins, they can! For example, say they want to add C++ support and we don't provide it yet, they can fill that gap themselves. As for your other concerns, v2 is all about just moving to a plugin system that allows us to build these plugins in isolation, outside of moon's Rust core. All the other features of moon, like configuration, tasks, projects, the pipeline, etc, will not be changing. |
Beta Was this translation helpful? Give feedback.
-
Our team is currently evaluating monorepo tools. I've been super excited about
moon
after discovering it. For the most part a PoC usingmoon
has been easy to setup. We are a smaller team so we don't need anything crazy. I love that you are distinguishing yourselves as a repo management tool and would get value out of the other features.However, compared to
nx
,moon
hasn't been around as long. It doesn't quite have the test of time. There's less community adoption so as a team we've been hesitant to commit. We were about to take the plunge but then saw the v2 announcement and it has us pulling back not knowing how big of change v2 will bring and if it will be an improvement.I'm not a fan of
nx
, one reason is the plugin system. I don't want to learn another abstraction layer over all our tooling (i.e. typescript, eslint, jest, esbuild, webpack, etc.). I want it as close to the configuration and the tooling as possible, and shell scripts get me there.I guess I wanted to share my perspective because I really like what your team is bringing to the table but have concerns over adoption regarding v2.
Beta Was this translation helpful? Give feedback.
All reactions