What wrong with using package.json?

[tomdavidson]

Nice! Excited about giving moon a go.

In the .moon/workspace.yml file we define the package manager, workspaces, and the node engine, but these are already defined and expected elsewhere. For example:

• corepack looks to packageManager in the package.json
• tools such as pnpm looks to engines and engines-strict in package.json and
• obviously, npm and yarm both look to workspaces in the package.json too (not sure why pnpm needs its own file).

In the Project Config we also have dependsOn which seems even more odd (different than what I am use to) not to configure deps in a project's package.json.

The moon cli even has moon migrate from-package-json. So... whats wrong with package.json?

[milesj]

@tomdavidson All of the node settings in .moon/workspace.yml are for configuring the toolchain, which is a system that will download and install both Node.js and the package managers behind the scenes, and then execute every task with them. moon will not use the Node.js installed on your system. This is to ensure the same version of tooling is ran on every developers machine, and in CI, and anywhere else.

You can view the docs for more information: https://moonrepo.dev/docs/concepts/toolchain

moon will also sync packageManager, engines, and everything else automatically. So instead of updating N locations when upgrading Node.js/etc, you simply update .moon/workspace.yml.

Because moon is written in Rust, and because language support is basically a plugin like system, relying on all those different settings instead of a standardized config is very difficult.

[tomdavidson]

Thanks for the quick response. So kind of a reverse "parcel config strategy" of using existing config files but kind of as artifacts rather than sources of truth so there is still compatibility for incremental adoption.

[milesj]

Yeah, it can be seen like that.