@mnci/cli 2.0.0 → 3.0.1

package/README.md

@@ -78,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 |
-| no retired formatter is still configured                | a leftover `.prettierrc.mjs` or `.oxfmtrc.json` runs from no command line, but a globally installed editor extension still resolves it and reformats on save, silently undoing Standard |
+| 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:
@@ -156,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.
@@ -181,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
@@ -198,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
@@ -254,15 +255,10 @@ 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.
+`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
@@ -412,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.
 
@@ -422,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.

package/dist/cli.js

@@ -1510,15 +1510,21 @@ ${ESLINT_BLOCK_INVENTORY}//
 // a dependency, so \`npm update\` brings rule fixes in the way it brings any
 // other. An override here survives that; an edit to the package does not.
 //
-// One override cannot work, and it is the one people reach for first:
-// \`space-before-function-paren\`. Prettier rewrites \`f (a)\` to \`f(a)\` on every
-// run, so switching that rule on makes \`npm run lint\` and \`npm run format:check\`
-// impossible to satisfy at the same time. Formatting lives in .prettierrc.mjs.
+// FORMATTING IS LINTING HERE. There is no Prettier, no oxfmt and no
+// \`format:check\` \u2014 \`npm run lint\` reports indentation, quotes and spacing as
+// ordinary errors, and \`npm run format\` is \`eslint . --fix\`. So do not add a
+// formatter: whichever one you pick will disagree with the \`mnci/standard\`
+// block above, and because a formatter runs on save it wins silently, leaving
+// \`lint\` to fail on files you never edited by hand.
+//
+// That also applies to the editor. Installing a Prettier or oxfmt extension is
+// enough on its own \u2014 neither needs a config file, and with none present they
+// format against their own defaults (semicolons, double quotes), which is the
+// inverse of Standard.
 export default mnci({ workspaceRoot: import.meta.dirname })
 `;
 var VSCODE_RECOMMENDED_EXTENSIONS = [
   "dbaeumer.vscode-eslint",
-  "esbenp.prettier-vscode",
   "nrwl.angular-console",
   "firsttris.vscode-jest-runner"
 ];
@@ -1551,9 +1557,9 @@ function vscodeSettings() {
     // does that comparison BEFORE scope. So a `[typescript]` block in someone's
     // USER settings — left over from any other project — outranks this file's
     // workspace-level `editor.defaultFormatter`, and format-on-save quietly uses
-    // that other formatter instead. Nothing reports it: Prettier is installed,
-    // the config resolves, `npm run format:check` still finds the 68 unformatted
-    // files, and the editor simply never applies it.
+    // that other formatter instead — and nothing reports it, because the gate
+    // and the editor are looking at different tools. That is how it was found:
+    // reported from a real workspace, not deduced from the docs.
     //
     // Reported from a real workspace where `.ts` files were not being formatted
     // while `.json`/`.jsonc`/`.yaml` were — exactly the three that had explicit