Commonality 1.0

[alec-chernicki]

• Customizable workspaces
• Simplified JSON configuration file and checks usage (commonality.json)
• Application view in Commonality Studio
• Customizable package detection for NX integrated monorepos

[alec-chernicki]

We'll be moving to a model project configuration is located at:

.commonality/
 |  has-buildable-scripts.ts
 |- config.json

where checks will be resolved by path or module resolution import.

Via path:

{
  "checks": {
    "*": [
      "has-buildable-scripts"
    ]
  }
}

Via external package using shortened syntax when using commonality-checks prefix (commonality-checks-recommended):

 {
  "checks": {
    "*": [
      "recommended/has-buildable-scripts"
    ]
  }
}

Via external package using shortened syntax when using any scope:

 {
  "checks": {
    "*": [
      "@scope/my-checks/has-buildable-scripts"
    ]
  }
}

rather than a commonality.config.ts or commonality.config.js file at the root of the repository. Writing custom dynamic checks that are specific to your workflows is the core draw of Commonality. It's way too easy to just write your checks directly in the configuration file and quickly have it become a nightmare.

Using JSON reduces complexity and encourages compositional patterns while allowing for local and external checks. It also is closer to conventions used by ESLint, further conveying the use of it as a linter-like tool.

[beaussan]

Using JSON reduces complexity and encourages compositional patterns while allowing for local and external checks. It also is closer to conventions used by ESLint, further conveying the use of it as a linter-like tool.

For what it's worth, this is no longer a convention in ESLint as flat config is the default for ESLint 9+, and it's only a js/ts file format : https://eslint.org/docs/next/use/configure/configuration-files