Supporting NX integrated monorepos

[alec-chernicki]

Commonality is currently optimized to work with multi-package monorepos where each package has a package.json file. I want to make sure that's super solid and introduce a few more core features like an init command and support for bun before expanding support to integrated monorepos. However, a few folks have expressed interest in a tighter integration with NX and I want to kick off the conversation that will help shape what that implementation will look like.

Current functionality

Here's how we currently construct the dependency graph:

1. We look for your package manager's version of "workspaces" and use those globs to determine where we should look forpackage.json files.
2. We recursively find all those directories and pull the name property from the package.json. Every package in Commonality must have a name.
3. We look through each packages dependencies, devDependencies, and peerDependencies for packages that are also included in the workspace. If it exists then it is added to the list of packages that appear in checks, constraints, and Commonality Studio.

Possible solutions

For item 1 we'll probably need to add a property that will serve as an override to the workspaces property, that way you can pass globs to mimic that functionality without affecting your package manager's functionality when adding it to your root package.json or a pnpm-workspaces.yaml file.

For items 2 and 3 I'd love some insight as there are several roads we can go down.

• We could auto-detect that you have an nx.json file and use the nx devkit to calculate the graph but that introduces a coupling to the NX devkit and project which could be totally fine.
• We could allow consumers to pass in their own package resolution logic through config and provide a package to do that specifically for the NX graph, but that would make an NX setup more brittle and unwieldy.

Open questions

• How are you using NX tags today? Is it only for constraints with their ESLint config?
• NX's documentation notes that a package.json is created when generating an integrated package. If we require that this file exists, even if it only contains a name property would that mess up your existing tooling?
• Some of the checks currently in commonality-checks-recommended rely on the existence of a package.json file. If there is no guarantee that a package.json exists what would be the

If you have any additional ideas I'd love to hear them!

[beaussan]

My wish list as an Nx user to migrate to commonality

Here is my dream wish list from an Nx setup user for commonality, integrated or package based:

• Detect automatically all modules in the workspace, integrated or package based
  • Today it will detect all package based modules within the mono, but not integrated modules
• Have access to the nx graph and / or the project infered configuration from the nx graph
  • This can be done with an async call to createProjectGraphAsync every check today but can slow down commonality significantly
  • As of why, currently I've wrote a handful of checks to verify the inferred configuration on a project based on the compute of nx crystal plugin, nx.json, package.json and project.json to ensure they match a desired configuration

Possible Solutions mentioned

We could auto-detect that you have an nx.json file and use the nx devkit to calculate the graph but that introduces a coupling to the NX devkit and project which could be totally fine.

Could this be done in a plugin approach way ? "commonality/nx" that enable this, and also inject the graph and project configuration in checks

We could allow consumers to pass in their own package resolution logic through config and provide a package to do that specifically for the NX graph, but that would make an NX setup more brittle and unwieldy.

That is also another way to do it, if we can also add extra things in the context of a check, this would be nice, especially with a a "commonality/nx" package, this way you don't introduce a hard dependancy with Nx within commonality, while allowing for extending it with Nx

My own response to the open questions:

How are you using Nx tags today? Is it only for constraints with their ESLint config?

In many of my workspace, I use tags for:

• module boundaries across multiple dimentions (as in, "platform:web/node/agnostic", "scope:scopeA/scopeB/shared")
• Some extra ones like "legacy" or "publishable" to add spesific rules around them, for ex, a project not tagged with legacy cannot import a legacy package

Nx's documentation notes that a package.json is created when generating an integrated package.

A root package.json is guarantee, but a package.json in a library is not always generated, it depends on the generator. Even more, in Nx Crystal, most generator don't generate any package.json.

If we require that this file exists, even if it only contains a name property would that mess up your existing tooling?

No, it's pretty safe to have one with only the name property

Some of the checks currently in commonality-checks-recommended rely on the existence of a package.json file. If there is no guarantee that a package.json exists what would be the

In theory, only a project.json is required per library, but with Nx Crystal and the inference system, they are technically not needed anymore (especially in polyglot repos for ex)