@rtorcato/repo-tooling 2.59.0 → 3.1.0

package/dist/cli/commands/doctor.js

@@ -5,6 +5,7 @@ import { resolveLanguageModule } from '../../languages/registry.js';
 import { SWIFT_GIT_HOOKS, runSwiftChecks } from '../../languages/swift/checks.js';
 import { detectLanguage } from '../utils/detect-language.js';
 import { checkGitHubSettings } from '../../base/github-settings.js';
+import { checkGitIdentity } from '../../base/git-identity.js';
 import { LOCKFILE_VERSION, readLockfile } from '../utils/lockfile.js';
 import { declinedInLock, getFixTargetForCheck } from './fix-targets.js';
 import { checkAiSetup, checkCodeowners, checkCodeQL, checkCommunityHealth, checkCoverageUpload, checkDependabot, checkEditorConfig, checkFile, checkGitHooks, checkGitHubActions, checkGitLabCI, checkPrePushHook, checkReadmeBadges, COMMITLINT_FILE_CHECK, } from '../../base/checks.js';
@@ -140,6 +141,7 @@ function demoteDeclined(results, lock) {
 async function runBaseChecks(dir, lock, opts) {
     const results = [];
     results.push(checkLockfile(lock));
+    results.push(await checkGitIdentity(dir));
     results.push(await checkEditorConfig(dir));
     results.push(await checkFile(dir, COMMITLINT_FILE_CHECK));
     if (opts.hooks) {

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@rtorcato/repo-tooling",
-	"version": "2.59.0",
+	"version": "3.1.0",
 	"description": "One CLI to scaffold, audit and fix your repo's whole toolchain — linting, tests, commits, releases & CI.",
 	"type": "module",
 	"keywords": [

package/tooling/semantic-release/github.mjs

@@ -43,6 +43,13 @@ export default {
 			{
 				assets: ['CHANGELOG.md', 'package.json', 'README.md'],
 				message: 'chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}',
+				// Don't label the "release is failing" issue. The default is
+				// ['semantic-release'], and GitHub rejects issue creation outright when
+				// the label doesn't exist on the repo — so a failed release fails *again*
+				// with a 422 that buries the real error under an octokit stack trace.
+				// false keeps the issue (and its post-mortem) without requiring every
+				// consuming repo to pre-create a label.
+				labels: false,
 			},
 		],
 		[

package/tooling/biome/README.md

@@ -1,90 +0,0 @@
-# Biome Configuration
-
-This package provides a standardized Biome configuration for consistent code formatting and linting across projects.
-
-## Installation
-
-```bash
-npm install -D @rtorcato/repo-tooling @biomejs/biome
-```
-
-## Usage
-
-### Option 1: CLI Copy Command (Recommended)
-
-```bash
-npx @rtorcato/repo-tooling copy biome
-```
-
-This will copy the base `biome.json` configuration to your project root.
-
-### Option 2: Manual Copy
-
-```bash
-cp node_modules/@rtorcato/repo-tooling/tooling/biome/biome.json ./biome.json
-```
-
-### Option 3: Reference in package.json
-
-```json
-{
-  "scripts": {
-    "lint": "biome lint .",
-    "format": "biome format .",
-    "check": "biome check .",
-    "check:fix": "biome check --fix ."
-  }
-}
-```
-
-## Configuration Features
-
-- **Formatter**: Tab indentation, 100 character line width, single quotes
-- **Linter**: Recommended rules with sensible overrides
-- **JavaScript**: ES5 trailing commas, semicolons as needed
-- **Import organization**: Disabled to prevent conflicts
-- **File patterns**: Excludes common build/config directories
-
-## Customization
-
-After copying the configuration, you can customize it for your project:
-
-```json
-{
-  // Add project-specific rules
-  "linter": {
-    "rules": {
-      "recommended": true,
-      "suspicious": {
-        "noExplicitAny": "error"
-      }
-    }
-  },
-  // Add project-specific file patterns
-  "files": {
-    "includes": [
-      "src/**/*",
-      "!src/generated/**"
-    ]
-  }
-}
-```
-
-## VS Code Integration
-
-Add to your `.vscode/settings.json`:
-
-```json
-{
-  "editor.defaultFormatter": "biomejs.biome",
-  "editor.formatOnSave": true,
-  "editor.codeActionsOnSave": {
-    "quickfix.biome": "explicit",
-    "source.organizeImports.biome": "explicit"
-  }
-}
-```
-
-## Why Biome Can't Extend Configurations
-
-Unlike ESLint or TypeScript, Biome doesn't support configuration inheritance/extending. Each project needs its own complete `biome.json` file. This package provides a well-tested base configuration that you can copy and customize.

package/tooling/changesets/README.md

@@ -1,35 +0,0 @@
-# Changesets preset
-
-Shared [Changesets](https://github.com/changesets/changesets) configuration for projects using `@rtorcato/repo-tooling`.
-
-Changesets is a **monorepo-friendly alternative to semantic-release**. The release workflow is the same shape (CI bumps versions, generates a changelog, publishes to npm), but the *intent* is captured in changeset markdown files at PR time rather than parsed from commit messages.
-
-Pick one — Changesets or semantic-release — per repo. The `doctor` check flags repos configured for both.
-
-## Usage
-
-```bash
-npx @rtorcato/repo-tooling copy changesets
-```
-
-This scaffolds `.changeset/config.json` from this preset. After that:
-
-```bash
-pnpm changeset           # interactive — author a changeset for the current change
-pnpm changeset version   # consume changesets, bump versions, write CHANGELOG.md
-pnpm changeset publish   # publish to npm
-```
-
-CI typically runs the [Changesets release bot](https://github.com/changesets/action), which opens a "Version Packages" PR when changesets are present and publishes on merge.
-
-## Why pick this over semantic-release
-
-- **Monorepos** — Changesets handles multi-package version bumps in a way semantic-release doesn't out of the box.
-- **Explicit intent** — Authors declare a change's bump level in the changeset file rather than encoding it in commit message conventions, which is more forgiving for human commits.
-- **Pre-release flows** — `--snapshot` and `pre enter <tag>` are first-class.
-
-## Why pick semantic-release instead
-
-- **Single-package repos** — Less ceremony; nothing to author per change.
-- **Strict conventional-commits discipline already in place.**
-- **Existing CI built around the `npm run release` path.**

package/tooling/oxlint/README.md

@@ -1,25 +0,0 @@
-# Oxlint preset
-
-Shared [Oxlint](https://oxc.rs/docs/guide/usage/linter.html) configuration for projects using `@rtorcato/repo-tooling`.
-
-Oxlint is a Rust-based linter that's 50–100× faster than ESLint. It is intentionally **additive** to Biome — Biome handles formatting and the broad lint baseline, Oxlint adds a faster pass for the type-aware and import rules Biome doesn't cover yet.
-
-## Usage
-
-```bash
-npx @rtorcato/repo-tooling copy oxlint
-```
-
-This drops `.oxlintrc.json` at the project root, extending the conventions in this preset. Run it with:
-
-```bash
-pnpm oxlint
-# or
-npx oxlint
-```
-
-## Notes
-
-- Oxlint shares its rule catalog with ESLint's plugins (`typescript`, `unicorn`, `oxc`, `import`), so most ESLint rules you know already work here.
-- The preset disables Biome-overlapping rules to keep CI noise down — Biome stays the source of truth for formatting and the baseline lint set.
-- For projects without Biome, you can run Oxlint standalone and re-enable the `style` and `pedantic` categories.

package/tooling/typescript/README.md

@@ -1,49 +0,0 @@
-# `tsconfig`
-
-These are base shared `tsconfig.json` files from which all other `tsconfig.json`'s inherit.
-
-## Usage
-
-1. **Install this package** (if published as a package):
-   ```sh
-   pnpm add -D @your-org/tsconfig
-   # or
-   npm install --save-dev @your-org/tsconfig
-   # or
-   yarn add -D @your-org/tsconfig
-   ```
-
-2. **Extend the relevant config in your project `tsconfig.json`:**
-   ```jsonc
-   {
-     "extends": "./path/to/tooling/typescript/tsconfig.base.json", // or tsconfig.react.jsonc, etc.
-     // ...your overrides
-   }
-   ```
-   Replace the path with the config that matches your project type:
-   - `tsconfig.base.jsonc`: General base config
-   - `tsconfig.build.jsonc`: For npm package/library builds
-   - `tsconfig.react.jsonc`: For React apps
-   - `tsconfig.next.jsonc`: For Next.js apps
-   - `tsconfig.node.jsonc`: For Node.js/Express APIs
-   - `tsconfig.express.jsonc`: (If used) For Express APIs
-
-3. **Customizing:**
-   You can override or add any settings in your own `tsconfig.json` as needed.
-
-## Example
-
-```jsonc
-{
-  "extends": "../tooling/typescript/tsconfig.react.json",
-  // `~/*` and `@/*` → `./src/*` are inherited from the preset, anchored to this
-  // project via ${configDir} — no `baseUrl`/`paths` needed (baseUrl is deprecated
-  // in TS 5.9, removed in TS 7.0).
-  "include": ["src"]
-}
-```
-
-## Notes
-- These configs are meant to be shared and extended, not used directly.
-- Pick the config that matches your project type for best results.
-