chore(deps-dev): bump ultracite from 7.12.0 to 7.12.2 in /npm

[dependabot]

Bumps ultracite from 7.12.0 to 7.12.2.

Release notes

Sourced from ultracite's releases.

ultracite@7.12.2

Patch Changes

• 0f192a7: ultracite init no longer wipes an existing Biome config it can't read. Previously a biome.json or biome.jsonc with a syntax error, or a nested monorepo config with "extends": "//", was treated as empty and replaced with just the Ultracite extends, losing every other setting. Now:

  • A config with a syntax error is left unchanged, with a warning asking you to fix it and re-run init.
  • A nested config that extends the root config ("extends": "//") is left unchanged, since the Ultracite presets belong in the root config.
  • A string extends is turned into a list that also includes the Ultracite presets.
  • Updates edit the file in place, so comments and formatting in biome.jsonc are preserved.

  ultracite doctor and the check/fix resolution check now follow a nested config that extends "//" to the root config, instead of warning that the nested config doesn't extend ultracite/biome/core.

• c68ba48: ultracite check and ultracite fix handle their arguments and missing tools more reliably:

  • check now treats explicit files the way fix does. Oxlint only gets files it can lint, Prettier runs with --ignore-unknown, and oxfmt with --no-error-on-unmatched-pattern. Before, ultracite check README.md or ultracite check Dockerfile src/index.ts failed even though nothing was wrong.
  • Linter flags that take a value keep it, even when the value looks like a file: --tsconfig tsconfig.json, -c .oxlintrc.json, --config-path biome.json, --only lint/suspicious/noDebugger, --since origin/main and similar. Before, the value was treated as a lint target, so ultracite fix --tsconfig tsconfig.json skipped Oxlint entirely and only formatted tsconfig.json. Ultracite's own --claude, --codex, --hook and --unsafe never take a value, so the next argument is always a target.
  • ultracite fix --unsafe with the ESLint toolchain no longer fails with ESLint's "Invalid option '--unsafe'". ESLint has no unsafe fixes, so the flag is dropped with a warning.
  • A linter that isn't installed is reported with a plain message instead of a stack trace. The other tools still run first. Stylelint is optional in the ESLint toolchain, as ultracite doctor already said, so a project without it now skips CSS linting with a warning instead of failing. "No linter configuration found" is also printed without a stack trace.
  • Linters installed in the project's node_modules/.bin are found even when Ultracite isn't run through a package manager script, npx or bunx, for example ./node_modules/.bin/ultracite check.

• f61f393: ultracite init now looks for existing ESLint, Prettier and Stylelint configs in the same order the tools do, so when a project has more than one, init updates the one the tool actually loads. For example, Prettier reads .prettierrc.json before prettier.config.mjs, and ESLint reads eslint.config.js before eslint.config.mjs. Before, init could update a config the tool ignored and leave the active one in place. Stylelint's .stylelintrc.ts and stylelint.config.ts are now recognised too.

• 242cd2a: ultracite init now updates an existing .vscode/settings.json or .zed/settings.json in place, so your comments and formatting are kept. Before, the file was re-serialised as plain JSON, which stripped every comment. A settings file with a syntax error is now left unchanged with a warning. Before, it was rewritten with whatever part the parser could recover, which dropped the rest.

  For the ESLint toolchain, init now also installs the Prettier VS Code extension (esbenp.prettier-vscode), since the settings it writes make Prettier the default formatter. Before, only the ESLint extension was installed, so format-on-save did nothing until you added Prettier yourself.

• c273393: ultracite init now checks every flag value before it changes anything in the project. An unknown value for --linter, --pm, --frameworks, --editors, --agents, --hooks, --integrations or --js-plugins stops init with a message listing the valid values. Previously a misspelled --linter (for example --linter Biome) deleted every existing Biome, ESLint, Prettier, Stylelint, Oxlint and oxfmt config file and then crashed.

  When --linter is not passed and init runs without prompts (because of --quiet, CI, or flags such as --agents or --pm), it now keeps the linter the project is already set up with and only falls back to Oxlint when there is none. Running ultracite init --agents universal on a Biome project no longer migrates it to Oxlint. The interactive linter prompt also preselects the detected linter.

• 3cb2e71: Clearer wording in the CLI:

  • ultracite init --help now lists the valid values for --pm, --linter, --frameworks, --hooks and --integrations, and explains what --type-aware does for Biome and for Oxlint.
  • The agent rules file says "Oxlint + Oxfmt will catch most mechanical issues automatically" instead of "Oxlint + Oxfmt's linter will catch…".
  • init and upgrade say "Using pnpm (detected from the project)" instead of "Detected lockfile", since the package manager can also come from packageManager.
  • ultracite doctor spells "unrecognized" consistently, formats commands as code, and describes warnings as "Some checks have warnings" instead of "optional improvements".

• 6ae8be8: The ESLint nestjs preset imports @darraghor/eslint-plugin-nestjs-typed, but ultracite init --linter eslint --frameworks nestjs never installed it, so ESLint failed to load the config with "Cannot find package". init now installs the plugin with the preset, and ultracite upgrade installs the plugins of every framework preset your eslint.config.* imports, so existing NestJS projects pick it up on their next upgrade.

• a8e83bb: ultracite init now migrates an existing .oxlintrc.json, .oxfmtrc.json or .oxfmtrc.jsonc when it sets up Oxlint. Oxlint and oxfmt refuse to load any config when a JSON config sits next to oxlint.config.ts or oxfmt.config.ts, and init used to write the TS configs beside the JSON ones, so ultracite check and ultracite fix stopped working. Init now moves the JSON config's settings into the TS config and deletes the JSON file:

  • rules, overrides, env, plugins and other options become properties of the generated config.
  • ignorePatterns, settings and jsPlugins are added to the ones Ultracite generates instead of replacing them.
  • Ultracite extends entries become presets. Other extends paths can't be referenced from a TS config, so init names them in a warning.

  A JSON config that doesn't parse is left in place, and neither file is written.

  Re-running ultracite init also keeps what you added to oxlint.config.ts and oxfmt.config.ts: custom rules, overrides, ignorePatterns, settings and other properties, extra extends entries, your own imports and statements, and comments are carried over while the Ultracite parts are regenerated. Before, both files were regenerated from scratch. A config that doesn't parse is now left unchanged with a warning instead of being overwritten.

  ultracite doctor now fails when a JSON config and a TS config for Oxlint or oxfmt sit side by side, and suggests running init to migrate a lone .oxfmtrc.json.

• 981ef2f: ultracite init --linter oxlint no longer adds "type": "module" to package.json. That field changes how Node loads every .js file in the package, so CommonJS files such as a next.config.js, postcss.config.js or jest.config.js using module.exports stopped working after init.

  Instead, init writes the Oxlint and oxfmt configs as oxlint.config.mts and oxfmt.config.mts when the package isn't an ES module package (no "type" or "type": "commonjs"). A .mts file always loads as an ES module, with no MODULE_TYPELESS_PACKAGE_JSON warning on every run, and it works under "type": "commonjs". ES module packages ("type": "module") still get oxlint.config.ts and oxfmt.config.ts.

  Re-running init updates an existing config under the name it already has. The one exception is a .ts config in a "type": "commonjs" package, which Node can't load: init renames it to .mts and says so. ultracite doctor, linter detection and the stale-config cleanup all recognise the .mts names. doctor fails a .ts config in a CommonJS package, and fails when a .ts and an .mts config sit side by side.

  Requires oxfmt >= 0.59.0, the first release that finds oxfmt.config.mts on its own.

... (truncated)

Commits

• e948def Version Packages (#823)
• 84838a2 Note that adding hooks later keeps the project's linter
• 987468a Document --unsafe per toolchain and the new check, doctor and upgrade behavior
• 857e799 Describe how init updates existing configs in the migration guides
• 9eb8cbf Document init's linter detection, flag checks and quiet output
• 9c30c15 Raise the oxlint peer range to the first release that loads the presets
• 44d6997 Create agent and hook directories only after the path guard
• 3cb2e71 Tidy CLI help and messages
• f61f393 Look for ESLint, Prettier and Stylelint configs in the tools' own order
• 923667b Respect tsconfig strictNullChecks settings, including inherited ones
• Additional commits viewable in compare view