Supporting NX integrated monorepos #208
Replies: 1 comment
-
My wish list as an Nx user to migrate to commonalityHere is my dream wish list from an Nx setup user for commonality, integrated or package based:
Possible Solutions mentioned
Could this be done in a plugin approach way ? "commonality/nx" that enable this, and also inject the graph and project configuration in checks
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:
In many of my workspace, I use tags for:
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.
No, it's pretty safe to have one with only the name property
In theory, only a |
Beta Was this translation helpful? Give feedback.
-
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 forbun
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:
package.json
files.name
property from thepackage.json
. Every package in Commonality must have a name.dependencies
,devDependencies
, andpeerDependencies
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 rootpackage.json
or apnpm-workspaces.yaml
file.For items 2 and 3 I'd love some insight as there are several roads we can go down.
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.Open questions
package.json
is created when generating an integrated package. If we require that this file exists, even if it only contains aname
property would that mess up your existing tooling?commonality-checks-recommended
rely on the existence of apackage.json
file. If there is no guarantee that apackage.json
exists what would be theIf you have any additional ideas I'd love to hear them!
Beta Was this translation helpful? Give feedback.
All reactions