Communitygithub.com

Nuvraxis/nuvraxis-plugins

Configuration et règles Biome 2.5 pour les monorepos Nuvraxis : biome.json racine, paramètres de formateur, linter avec preset recommandé, domaines a11y/react/next, politique nursery, tri des imports, surcharges, configurations imbriquées, hooks VS Code et migration depuis ESLint/Prettier.

Qu'est-ce que nuvraxis-plugins ?

Ce skill configure et applique Biome 2.5 comme unique outil de formatage et de linting pour les monorepos Nuvraxis. Il centralise la configuration dans un fichier biome.json racine avec le schéma épinglé à la version installée, active le mode VCS pour ignorer les fichiers via git, et définit des règles précises pour le formateur (2 espaces, largeur 100, LF, guillemets doubles, points-virgules, virgules finales) ainsi que pour le linter (preset recommandé, a11y en erreur, domaines React et Next au niveau recommandé). Le skill gère également l'organisation automatique des imports, les surcharges par glob (notamment pour les fichiers de test), les configurations imbriquées avec héritage de la racine via `"extends": "//"`, et l'intégration avec VS Code (formateur par défaut, correction au sauvegarde). Enfin, il fournit des instructions claires pour migrer depuis ESLint/Prettier, supprimer les paquets et fichiers obsolètes, et utilise des hooks pour exécuter `biome check --write` après chaque édition de fichier par Claude. Les plateformes supportées incluent les monorepos JavaScript/TypeScript avec pnpm et VS Code.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Nuvraxis/nuvraxis-plugins/tree/HEAD/plugins/nuvraxis-frontend/skills/biome

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Biome

Biome est le seul formateur et linter pour JS, TS, JSX, JSON et CSS. SCSS est l'exception : Biome 2.5 ne le parse pas, donc stylelint gère les .scss (voir scss-bem). Pas d'ESLint, pas de Prettier.

Le biome.json racine du modèle est la source de vérité. Un hook du plugin exécute pnpm exec biome check --write <fichier> après chaque fichier édité par Claude, lorsqu'un biome.json existe au-dessus.

Règles

  1. Un seul biome.json racine, schéma épinglé à la version installée. "$schema": "https://biomejs.dev/schemas/2.5.15/schema.json", et @biomejs/biome épinglé à la même version dans le catalogue du workspace. Un schéma décalé masque les options inconnues ou renommées dans l'éditeur. Lors d'une mise à niveau, exécutez pnpm exec biome migrate --write et mettez à jour les deux.

  2. Laissez git décider ce qui est ignoré : vcs.useIgnoreFile: true. Forcez ensuite l'ignorance des sorties de build avec !! dans files.includes (!!**/.next, !!**/.turbo, !!**/dist, !!**/coverage), ce qui empêche également Biome de scanner ces dossiers. Un seul ! exclut du traitement mais indexe quand même. files.ignoreUnknown: true empêche les fichiers .scss et autres fichiers non supportés d'être signalés.

  3. Formateur : 2 espaces, largeur 100, LF, guillemets doubles, points-virgules, virgules finales. Ceux-ci sont fixes pour chaque dépôt, afin que les diffs ne se battent pas pour le style. N'ajoutez pas de surcharges de formateur par paquet.

  4. Linter : preset: "recommended", a11y: "error", domaines react et next au niveau recommended. rules.recommended: true est l'ancienne orthographe et est dépréciée : utilisez rules.preset. a11y en error car nuvui gère lui-même l'accessibilité de ses composants, donc ce qui reste (alt, labels, types de boutons dans votre propre balisage) doit être correct. Le domaine next ajoute des règles comme noImgElement ; react ajoute les règles des hooks.

  5. Nursery reste désactivée. Les règles Nursery changent entre les versions de patch et peuvent casser la CI lors d'une mise à niveau de Biome. Activez-en une délibérément, par son nom, avec un commentaire expliquant pourquoi, et revérifiez à chaque mise à niveau.

  6. noConsole avertit, en autorisant error et warn. Les logs d'erreur structurés (instrumentation.ts) utilisent console.error ; les console.log intempestifs sont détectés.

  7. Triez les imports avec l'assistant, pas à la main. assist.actions.source.organizeImports: "on". biome check --write l'applique ; biome ci échoue en cas d'imports non triés.

  8. Surcharges par glob, pour les fichiers de test et autres. Le modèle active le domaine test uniquement pour *.test.ts(x) / *.test-d.ts. Mettez-y aussi les autres différences de type de fichier, pas dans des configurations séparées.

  9. Configurations imbriquées uniquement pour les paquets qui diffèrent vraiment, et elles héritent de la racine.

    // packages/legacy-widget/biome.json
    { "extends": "//", "linter": { "rules": { "style": { "noNonNullAssertion": "off" } } } }
    

    "extends": "//" signifie "la configuration racine" et implique "root": false. Toute autre configuration imbriquée doit définir "root": false. Nous n'utilisons pas de paquet @repo/biome-config partagé : le fichier racine plus // suffit sans build ni dépendance.

  10. Localement biome check --write ; en CI biome ci. pnpm lint exécute biome check . (sans écriture) ; pnpm lint:fix exécute biome check --write .. La CI exécute pnpm exec biome ci --reporter=github ., qui n'écrit jamais, échoue en cas de problèmes de formatage, de lint et d'ordre des imports, et annote la PR. Ajoutez --changed --since=origin/main seulement si l'exécution complète devient lente ; c'est en millisecondes aujourd'hui.

  11. Supprimez une ligne, avec une raison.

    // biome-ignore lint/suspicious/noExplicitAny: third-party callback typed as any upstream
    

    Ne désactivez jamais une règle à l'échelle du dépôt pour faire passer un seul fichier. Si une règle est incorrecte pour le dépôt, modifiez biome.json dans son propre commit avec la raison.

  12. Corrigez, ne masquez pas, les plus courantes.

    • useImportType : exécutez la correction ; elle est requise par verbatimModuleSyntax.
    • noExplicitAny : utilisez unknown et parsez (voir typescript-production).
    • useButtonType, noSvgWithoutTitle, useAltText : de véritables bugs d'accessibilité.
    • noImgElement : utilisez next/image.
    • useExhaustiveDependencies : corrigez la liste des dépendances ou déplacez la valeur hors du composant.
  13. VS Code : Biome est le formateur par défaut, correction à la sauvegarde. Le .vscode/settings.json du modèle définit editor.defaultFormatter: "biomejs.biome", source.fixAll.biome et source.organizeImports.biome à la sauvegarde, et biome.requireConfiguration: true pour que l'extension reste silencieuse dans les dépôts sans Biome. SCSS conserve l'extension stylelint. Recommandez les deux dans .vscode/extensions.json.

  14. Migrer depuis ESLint/Prettier : migrez, puis supprimez. Voir references/migration.md. État final : aucun paquet eslint*, prettier* ou @typescript-eslint/*, aucun fichier .eslintrc*, eslint.config.*, .prettierrc*, .prettierignore.

Ce que Biome ne couvre pas

FichierOutil
.scssstylelint (scss-bem)
.yaml (workflows, Helm)actionlint pour les workflows ; helm lint + kubeconform pour les charts
.mdrien d'imposé
Erreurs de typetsc --noEmit (pnpm typecheck)

Vérifier

pnpm lint                               # biome check . && stylelint
pnpm exec biome ci --reporter=github .  # ce que la CI exécute
pnpm exec biome rage                    # affiche la configuration résolue si quelque chose semble ignoré

Sources

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

Nuvraxis/nuvraxis-plugins

>- Dockerfile rules for Next.js standalone apps in a pnpm + Turborepo monorepo — multi-stage build (turbo prune → pnpm fetch/offline install → turbo build → minimal runner), pinned Node 26 Alpine by digest, checksum-verified pnpm binary, non-root uid 1001, read-only root filesystem with a writable .next/cache, HEALTHCHECK on /api/health, build args only for NEXT_PUBLIC_* values, BuildKit secrets and cache mounts, multi-arch, OCI labels and .dockerignore. Use when the repo has a Dockerfile, .dockerignore, compose file, or next.config with output "standalone", or when asked to containerise, shrink, harden or debug an image.

Nuvraxis/nuvraxis-plugins

>- GitHub Actions conventions for Nuvraxis Next.js apps — exactly three workflows: pr.yaml (every PR to any branch: Biome, stylelint, typecheck/test/build with turbo --affected, Docker build + health check, helm lint + kubeconform; publishes nothing), main.yaml (push to main: one multi-arch image to GHCR tagged sha-SHORTSHA and main, provenance + SBOM, gha cache), release.yaml (tag vX.Y.Z: verify on main, retag the existing image without rebuilding, package and push the Helm chart to OCI, GitHub Release with chart, digest and SBOM). Minimal permissions per job, GITHUB_TOKEN only, pinned action majors. Use when editing .github/workflows/*, adding a CI step, or debugging a failed run or release.

Nuvraxis/nuvraxis-plugins

>- Helm chart rules for Nuvraxis Next.js apps — one chart per app in charts/ (named after the app), published to oci://ghcr.io/nuvraxis/charts and synced by Argo CD; Chart.yaml version/appVersion set only by release.yaml; Deployment with startup/liveness/readiness probes on /api/health, non-root read-only security context, emptyDir for .next/cache, ConfigMap + existing Secret via envFrom, Service, Ingress with cert-manager, HPA, PDB, ServiceAccount, topology spread; no Helm hooks; helm lint --strict + kubeconform. Use when the repo has charts/, Chart.yaml, values*.yaml, templates/*.yaml with Helm syntax, or an Argo CD Application, or when asked to deploy, scale, expose or configure the app on Kubernetes.

Nuvraxis/nuvraxis-plugins

>- Production rules for Next.js 16 App Router apps at Nuvraxis — Server/Client Component boundaries, Cache Components ("use cache", cacheLife, cacheTag, updateTag), Server Actions, route handlers, env handling, instrumentation, output standalone and the /api/health route. Use when the project has "next" in package.json, an app/ or src/app/ directory, next.config.ts, proxy.ts, instrumentation.ts, or files named page.tsx, layout.tsx, route.ts, loading.tsx, error.tsx.

Skills associés