The estate’s shared lint base, so a rule is argued once
The estate's shared ESLint base. One config every property extends, so a lint rule is argued once.
Adopting a linter used to mean writing a flat config from scratch in every repository, and most never got round to it — which is not a disagreement about style, it is a standard that costs forty lines per property. This is those forty lines, published once. Extending it costs three, and a separate entry point carries the Next rules so a repository with no framework does not have to install one to lint.
One flat config array, exported from the root entry point, plus a `./next` entry that spreads the base and adds Next’s core-web-vitals and TypeScript rules. The split is the whole design: the static generators in this estate extend the base and do not have Next installed, so an import moved into the root would break every one of them at once.
It also ships the ignore list — bundles, minified vendor files, committed build output — because pointing a linter at compiled code produces thousands of findings about code that is already compiled, which is how a repository ends up with a lint script nobody runs.
The config array is tested rather than assumed: an empty array would lint nothing while the lint script still exits zero, which is a green check over a repository nothing has looked at. The suite asserts the base is non-empty, that the ignore list covers the output nobody wrote, and — by reading the source — that the base entry point imports no framework package, which is the invariant the frameworkless properties depend on.
Apache-2.0, read from the package’s own manifest. Embed it in anything, including closed software — that is what makes a spec adoptable and a verifier worth running. FlashyOS’s server side is AGPL-3.0-only instead, and a test in the monorepo asserts the direction between them: AGPL code may consume this, this may never consume AGPL code.