@mnci/cli 1.19.8 → 3.0.0

package/README.md

@@ -30,7 +30,6 @@ first-party (or established community) Nx equivalent:
 mnci new my-repo            # create a monorepo (prompts scope + registry)
 mnci new my-repo --yes --registry npm --scope @my
 mnci new my-repo --yes --registry npm --scope @my --nx-cloud  # opt in to Nx Cloud
-mnci new my-repo --yes --registry npm --scope @my --linter oxlint  # Rust toolchain
 
 cd my-repo
 mnci add react-app web         # @nx/react (Vite + Jest)
@@ -79,14 +78,12 @@ ever needed is noise that trains people to ignore the output.
 | Check                                                   | The failure it catches                                                                                                                              |
 | ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
 | Exactly one root ESLint config, and no per-project ones | The config fragmenting — every `@nx/*` generator writes one, so each project ends up linting against whichever config sits nearest                  |
-| No stray `.prettierrc`                                  | It outranks `.prettierrc.mjs`, so the whole formatting opinion is silently discarded while both files look fine                                     |
 | `@nx/eslint/plugin` registered in `nx.json`             | Without it `npm run lint` exits 0 while linting nothing                                                                                             |
 | The **resolved** `eslint` major                         | A declared range and an installed version are different things — manifests once said `^10` while the pin said 9                                     |
 | `.npmrc` matches the recorded registry                  | The two registry kinds get different files; an Azure workspace also needs its scope routed                                                          |
 | `versionActions` on publishable Dart/Python packages    | Its absence aborts `nx release` for the **whole** workspace, not just that project                                                                  |
 | `nx sync:check`                                         | A stale TypeScript project reference that was never committed                                                                                       |
-| Only the chosen linter's config files present           | Two formatter configs is not a visible error — each is valid, the CLI picks one, the editor may pick the other, and the two gates disagree silently |
-| oxlint toolchain declared                               | `@mnci/oxlint-config` peers on `oxlint`, so a missing declaration turns `npm run lint` into "command not found" at the worst moment                 |
+| No retired formatter is still configured                | A leftover `.prettierrc*`, `.oxfmtrc.json` or `oxlint.config.ts`, or a `prettier`/`oxlint`/`oxfmt` devDependency, runs from no command line — which is what makes it dangerous, since an editor extension still resolves it and reformats on save, undoing Standard after every gate has passed |
 
 Everything else is plain Nx, surfaced as a small curated set of root scripts —
 each a single cross-platform command:
@@ -157,15 +154,14 @@ that would just fail felt worse than being upfront that it doesn't exist yet.
    nothing at all while reporting green.
 3. Writes `eslint.config.mjs` (one import from `@mnci/eslint-config` — the whole
    linting opinion, in one root config — plus a commented inventory naming every
-   config block and how to override it), `.prettierrc.mjs` (which re-exports
-   `@mnci/eslint-config/prettier`, so lint and format ship as one package and
-   upgrade together) + `.prettierignore`, `.npmrc` (publish auth — see **Publish auth** below),
+   config block and how to override it — there is no formatter config, because
+   ESLint is the formatter), `.npmrc` (publish auth — see **Publish auth** below),
    `commitlint.config.mjs`, a husky `commit-msg` hook, the chosen CI provider's
    pipeline file(s)
    (`azure-pipelines.yml` and/or `.github/workflows/ci.yml`, `--ci`, default
    `azure`; `github`/`both` also gets `.github/dependabot.yml` — weekly
    dependency-update PRs), a `<workspace-name>.code-workspace` file (VS Code
-   workspace configuration with folder structure, ESLint/Prettier settings,
+   workspace configuration with folder structure, ESLint settings,
    recommended extensions, and an empty `tasks` array that `mnci add` fills in
    per project — see below — open it in VS Code via `File > Open Workspace
 from File`), and the curated root scripts.
@@ -182,12 +178,12 @@ same options `new` would have and calls the exact same `applyOverlay` `new`
 itself calls — the one function that does every bit of `mnci`-owned file
 writing (`nx.json`'s `release`/`sync`/`generators`/`namedInputs.sharedGlobals`/
 `mnci` blocks, `.npmrc`,
-`eslint.config.mjs`, `.prettierrc.mjs`, `commitlint.config.mjs`,
+`eslint.config.mjs`, `commitlint.config.mjs`,
 `.husky/commit-msg`, the CI pipeline file(s), `.devcontainer/devcontainer.json`, the
 `<workspace-name>.code-workspace` file, and the curated root `package.json`
 scripts). Nothing else in the workspace — app/lib source, `project.json` targets
-from `mnci add` — is ever touched, and it finishes by running Prettier over the
-result, the same way `new` and every `add` do.
+from `mnci add` — is ever touched, and it finishes by running `eslint --fix`
+over the result, the same way `new` and every `add` do.
 
 The `.code-workspace` file is the one partial case, and deliberately so: its
 folders, settings and extensions are regenerated, but the **`tasks` array is read
@@ -199,10 +195,14 @@ project's build/qa/start entry on upgrade.
 has always done — one more reason to run `git diff` first, as the command's own
 output tells you to:
 
-- `create-nx-workspace`'s `.prettierrc` and `.vscode/`, plus mnci's own former
-  `.prettierrc.json`. The two Prettier files are deleted for the same reason:
-  both outrank `.prettierrc.mjs`, which Prettier would otherwise never reach.
-  `.vscode/` is superseded by the `.code-workspace` file.
+- `create-nx-workspace`'s `.prettierrc` and `.vscode/`, plus every formatter
+  config a past mnci version wrote — `.prettierrc.json`, `.prettierrc.mjs`,
+  `.prettierignore`, `.oxfmtrc.json`, `oxlint.config.ts`. None of them runs from
+  a command line any more, and that is exactly what makes them dangerous: a
+  globally installed `esbenp.prettier-vscode` or `oxc.oxc-vscode` still resolves
+  one and still reformats on save, undoing Standard while `lint` stays green
+  because the damage lands after the check. `.vscode/` is superseded by the
+  `.code-workspace` file.
 - **every per-project `eslint.config.*` under `apps/`, `libs/` and
   `packages/`.** This is the migration path for a workspace generated before
   mnci owned linting: without it an upgrade would install the root config while
@@ -255,100 +255,35 @@ a `lint` target" and "the root config genuinely reports violations in a project
 with no config of its own", because a future Nx change there would silently
 switch linting off workspace-wide.)
 
-ESLint handles code quality only; **Prettier owns all formatting**, configured
-for JavaScript Standard Style (no semicolons, single quotes, 2-space indents, no
-trailing commas). Both opinions come from the same package: `.prettierrc.mjs`
-re-exports `@mnci/eslint-config/prettier`, so a formatting fix arrives through
-`npm update` exactly as a rule fix does, and the two cannot drift into
-contradicting each other. `mnci` runs Prettier itself at the end of `new` and every
-`add`, so a generated workspace passes its own `format:check` immediately — Nx's
-generators emit semicolons and double quotes, and without that pass the first
-commit buries every real change under generator noise.
-
-**Choosing the linter.** `--linter=eslint` (default) or `--linter=oxlint`, also a
-prompt at `mnci new` and overridable on `mnci upgrade`. The formatter rides along
-— ESLint pairs with Prettier, oxlint with oxfmt — because both are the same seven
-Standard options, so the choice is about speed and toolchain, never about how the
-code ends up looking.
-
-**`oxlint` is a hybrid, not a swap**, and that is deliberate. oxlint parses
-JS/TS/JSX/Vue and nothing else, so an oxlint workspace keeps a trimmed ESLint
-config (`@mnci/eslint-config`'s `nonJs()`) for the file types oxlint cannot read:
-
-|                                 | `eslint`                               | `oxlint`                                                 |
-| ------------------------------- | -------------------------------------- | -------------------------------------------------------- |
-| JS/TS lint                      | ESLint, 452 rules                      | oxlint, 206 native + 225 bridged                         |
-| YAML/TOML/MD/CSS/HTML/JSON lint | ESLint                                 | **ESLint** (unchanged)                                   |
-| `@nx/dependency-checks`         | yes                                    | **yes** (unchanged)                                      |
-| Formatter                       | Prettier                               | oxfmt (~6x faster on this repo)                          |
-| Formats `.toml`                 | no — Prettier has no TOML parser       | **yes**                                                  |
-| Config files                    | `eslint.config.mjs`, `.prettierrc.mjs` | `oxlint.config.ts`, `.oxfmtrc.json`, `eslint.config.mjs` |
-| VS Code extension               | ESLint + Prettier                      | Oxc (covers both) + ESLint                               |
-
-A pure swap was considered and rejected: it would leave a duplicate key in a CI
-pipeline, a malformed `pyproject.toml`, and a publishable package's wrong manifest
-all reported by nothing. Switching modes with `mnci upgrade --linter=<other>`
-rewrites the config files **and deletes the mode you left**, so a workspace never
-carries two formatter configs.
-
-**Exactly one formatter is declared, and that is a fix rather than tidiness.**
-`prettier` under `eslint`, `oxfmt` under `oxlint`, and switching modes drops the
-other from `devDependencies`. prettier stays in `node_modules` either way, since
-`@mnci/eslint-config` depends on it — so what matters is the _declaration_:
-`esbenp.prettier-vscode` resolves the formatter from the **project's**
-dependencies, so an oxlint workspace that still declared prettier is one where a
-globally installed Prettier extension reformats on save against the opinion oxfmt
-is not applying, while `npm run format:check` (oxfmt) reports the result as
-unformatted. Both configs valid, both binaries resolvable, neither one wrong on
-its own — the `.prettierrc` precedence bug in another costume. `mnci doctor`
-checks it.
-
-**oxfmt formats `.toml`; Prettier cannot.** `prettier` on a `.toml` exits with
-`No parser could be inferred for file`, so an oxlint workspace gets a formatted
-`pyproject.toml` and the default cannot — the one gap
-`@mnci/eslint-config`'s parser-only TOML block has always documented as
-unenforceable. It is the only file type where the two formatters differ in what
-they can parse, which is why `[toml]` is pinned for format-on-save under `oxlint`
-only: pinning it under `eslint` would route the file to a formatter that errors
-on it.
-
-**Finding and overriding a rule.** One root config importing a package is easy to
-own and hard to read: nothing in three lines says which of ~20 plugins reported
-the thing you disagree with. Every block in `@mnci/eslint-config` therefore
-carries a `name` — `mnci/base`, `mnci/react`, `mnci/type-aware`,
-`mnci/prettier-compat` — and the generated `eslint.config.mjs` ships the full list
-as a comment, next to the recipe for overriding one. `npx eslint --inspect-config`
-lists them as ESLint actually resolves them, `npx eslint --print-config <file>`
-shows the merged result for a single file, and an override is a named block
-appended after the spread, since later blocks win. Don't edit the package inside
-`node_modules`: it is a dependency, and `npm update` will replace it.
-`packages/eslint-config/README.md` has the block-by-block table.
-
-One caveat worth knowing: `space-before-function-paren`, Standard's signature
-rule, is **not** enforced. Prettier rewrites `function f (a)` to `function f(a)`
-on every run and has closed the corresponding option permanently, so enabling it
-would make `npm run lint` and `npm run format:check` mutually unsatisfiable.
-Choosing Prettier means accepting its call there.
-
-`npm run lint` checks code quality; `npm run format` (write) and
-`npm run format:check` (CI-safe) handle formatting. **Both run in CI**, as
-separate steps: ESLint is configured for correctness only and deliberately
-reports nothing about formatting, so Prettier needs a gate of its own or the
-whole formatting opinion is advisory and a workspace drifts out of compliance
-with no signal anywhere.
-
-TypeScript is not a question — every workspace runs the **dual compiler** from
-[Nx's TS 7 guide](https://nx.dev/docs/technologies/typescript/guides/typescript-7):
-`typescript` resolves to a TS 6 package (keeping the programmatic API that Nx's
-graph/plugins, Vite, typescript-eslint and the editor need) while
-`@typescript/native` provides TS 7's native `tsc`. The inferred
-`typecheck`/`build` tasks then run on the **fast TS 7 compiler**, and Nx keeps
-analysing config through the TS 6 API — no target rewiring, frozen per repo by
-the lockfile. (A plain `typescript@7` install would break Nx, since TS 7 ships
-no programmatic API yet; the two aliases are what make it work.)
-
-- **Test runner**: passed straight to the `@nx/*` generators; the function app
-  gets a matching `jest.config.mjs` (+ ts-jest) or `vitest.config.ts`.
+`mnci` runs `eslint --fix` itself at the end of `new` and every `add`, so a
+generated workspace passes its own `lint` immediately — Nx's generators emit
+semicolons and double quotes, and without that pass the first commit buries every
+real change under generator noise.
+
+**One linter, which is also the formatter.** There is no `--linter` flag and no
+choice to make: `@mnci/eslint-config` carries code quality, type-aware rules and
+JavaScript Standard Style formatting in a single ESLint config at the root.
+`npm run format` is `eslint . --fix --cache`; there is no `format:check`,
+because `lint` already reports formatting as ordinary errors with a rule name,
+a line and a column.
+
+That is the point of the arrangement rather than a side effect. A formatter and
+a linter that both hold style opinions have to be kept in agreement, and the
+older setup dodged that only by having ESLint hold *no* style opinion at all —
+which is exactly why a formatting mistake produced no squiggle and no message in
+the editor. It also makes `space-before-function-paren` enforceable for the
+first time: every Prettier-compatible formatter, oxfmt included, rewrites
+`function f (a)` back to `function f(a)`.
+
+**Upgrading an older workspace.** `mnci upgrade` deletes every config a previous
+version could have written for a second tool — `.prettierrc`, `.prettierrc.json`,
+`.prettierrc.mjs`, `.prettierignore`, `.oxfmtrc.json`, `oxlint.config.ts` — and
+drops `prettier`, `oxlint`, `oxfmt` and `@mnci/oxlint-config` from
+`devDependencies`. Both halves matter: the files are inert from the command line,
+but an editor extension still resolves them, and the VS Code extension resolves a
+formatter from the **project's** dependencies, so a stale declaration is enough
+to reformat on save against an opinion nothing checks. `mnci doctor` reports a
+workspace that has not been upgraded yet.
 
 ## Layout convention = release scoping
 
@@ -473,8 +408,8 @@ vulnerable transitive package) is exactly what this monorepo's own
 attempts automatically.
 
 Then `nx sync:check` (fails fast and clearly if the workspace wasn't
-synced+committed locally — see above), then `npm run format:check`, then **one
-verify step** running `lint,typecheck,test,build`. `typecheck` is in that list
+synced+committed locally — see above), then **one verify step** running
+`lint,typecheck,test,build`. `typecheck` is in that list
 because a bundler-built project strips types without reading them, so `build`
 passing proves nothing about type correctness.
 
@@ -483,9 +418,10 @@ project on anything else — including a push to `main`, so a release is always
 verified in full. There is deliberately no separate `npm run lint` step: that is
 `nx run-many -t lint`, a strict subset of the list above, and on an
 affected-scoped PR it would re-lint every project and throw the benefit away.
-`format:check` does stay workspace-wide, because `prettier --check .` is one
-invocation over the whole tree rather than a per-project target, so there is
-nothing to narrow.
+
+There is no `format:check` step either, and its removal is not a saving but a
+consequence: `lint` reports formatting itself now, so a second step would run
+the same binary twice over the same tree.
 
 Every fallback in that step verifies **everything**: no PR target branch, an
 unresolvable merge-base (shallow clone, absent remote branch), any non-PR run.