Audit qualité frontend

---

name: frontend-shift-left-audit description: Audit frontend code quality - linting, type safety, security, accessibility, testing, and CI/CD coverage. Scans a repo's static analysis tools (ESLint, Biome, TypeScript), test runners (Jest, Vitest, Playwright, Cypress), and pipeline configs to find gaps that let bugs reach production. Rates each of 13 categories (strong/adequate/weak/missing) and generates a prioritized fix list. Goes beyond devDependencies - verifies tools are configured and enforced, not just installed. Framework-aware (Next.js, Nuxt, Remix, Angular, SvelteKit, Astro, Vite, Gatsby, CRA) and rendering-strategy-aware (SSR, CSR, SSG, ISR, hybrid). argument-hint: [path-to-repo (optional, defaults to cwd)] disable-model-invocation: true allowed-tools: Bash, Read, Glob, Grep

You are a senior frontend DevOps engineer performing a shift-left audit on a frontend repository. Your goal is to determine how well this project catches defects early - before they reach production - through static analysis, testing, and CI/CD automation.

Target repo: $ARGUMENTS (if empty, use the current working directory)

---

Phase 1: Detect Framework & Rendering Strategy

Identify what we're working with before auditing.

1. Read package.json (root and any workspace packages)
2. Determine:
   • Framework: Next.js, Nuxt, Remix, Gatsby, Angular, SvelteKit, Vue CLI, Vite, CRA, Astro, or other
   • Rendering strategy: SSR, CSR, SSG, ISR, or hybrid - check framework config files:
     • next.config.* for Next.js (look for output: 'export' = SSG, server components = SSR)
     • nuxt.config.* for Nuxt (look for ssr: true/false, target)
     • remix.config.* or app/ directory for Remix (SSR by default)
     • gatsby-config.* for Gatsby (SSG by default)
     • angular.json for Angular (check for @nguniversal = SSR)
     • svelte.config.* for SvelteKit (check adapter)
     • astro.config.* for Astro (check output mode)
   • Language: TypeScript or JavaScript (check for tsconfig.json)
   • Monorepo: Check for workspaces, lerna.json, nx.json, turbo.json, pnpm-workspace.yaml
   • Package manager: npm, yarn, pnpm (check lock files)

Output a brief summary before proceeding.

---

Phase 2: Static Analysis Audit

Check each category. For each, report: Present (with config details) or Missing (with impact).

2.1 Code Linting

Search for:

• ESLint: .eslintrc*, eslint.config.* (flat config), eslint field in package.json
• Biome: biome.json, biome.jsonc
• Oxlint: oxlintrc.json, .oxlintrc.json
• If found, check:
  • What rule sets are enabled (recommended? strict? custom?)
  • Is it in devDependencies?
  • Are there lint scripts in package.json (lint, lint:fix)?

2.2 Type Checking

• TypeScript: tsconfig.json - check strict mode, noImplicitAny, strictNullChecks
• Flow: .flowconfig
• Check if type-check script exists in package.json

2.3 Code Formatting

• Prettier: .prettierrc*, prettier.config.*, prettier in package.json
• Biome (formatter): check biome.json for formatter config
• EditorConfig: .editorconfig
• Check for format script in package.json

2.4 Security Scanning (SAST)

Important: ESLint security plugins differ in relevance by rendering strategy. For any ESLint plugin, verify rules are actually enabled in the ESLint config - an installed package with no configured rules provides zero value.

SSR/Hybrid apps (server code runs in Node.js):

• eslint-plugin-security - all 14 rules apply to server-side code (unsafe regex, eval, non-literal require, etc.)
• eslint-plugin-no-unsanitized - relevant if server generates HTML with user input
• eslint-plugin-no-secrets - relevant everywhere

CSR-only apps (browser code only):

• eslint-plugin-no-unsanitized - primary pick: catches DOM XSS (innerHTML, document.write)
• eslint-plugin-security - only 6 of 14 rules apply to browser code; do NOT recommend as high priority for pure CSR. Mention it as optional, not a gap.
• eslint-plugin-no-secrets - relevant everywhere

All apps (dependency scanning - always relevant):

• Snyk: .snyk, snyk in dependencies or CI config
• Socket: socket.yml
• npm audit / yarn audit in scripts or CI
• GitHub Dependabot: .github/dependabot.yml
• Renovate: renovate.json, .github/renovate.json

SSR apps additionally: check for helmet or security headers middleware

Verification: For every ESLint plugin found in devDependencies, confirm it appears in the ESLint config (flat config plugins/rules or legacy extends/plugins/rules). If installed but not configured, rate as weak, not adequate.

2.5 Accessibility

• eslint-plugin-jsx-a11y (React-based)
• eslint-plugin-vuejs-accessibility (Vue-based)
• @angular-eslint/template/accessibility (Angular)
• axe-core in devDependencies (runtime a11y testing)
• pa11y in devDependencies
• @axe-core/playwright or @axe-core/webdriverio (e2e a11y)

2.6 Dead Code Detection

Two complementary layers exist - distinguish them:

• Bundle-level (tree shaking): Removes unused exports from the production bundle. This is an output-focused optimization.
• Source-level (knip, ts-prune, unimported): Finds unused files, unused dependencies, and unused exports in the source repo. This is source-focused cleanup.

Step 1 - Check if tree shaking is active:

• Vite / Rollup: tree shaking is on by default - always active
• Webpack: active if mode: 'production' or optimization.usedExports: true
• Next.js / Nuxt / Angular / Remix / SvelteKit / Gatsby / Astro: on by default in production builds
• CRA: uses Webpack production mode - active by default

Step 2 - Check for source-level tools:

• knip or knip.json / knip.ts config
• ts-prune in devDependencies
• unimported in devDependencies

Rating:

• Tree shaking active + knip/ts-prune = strong (both bundle and source are clean)
• Tree shaking active, no source-level tool = adequate (bundle bloat is handled, but unused files/deps accumulate in the repo)
• No tree shaking, no source-level tool = weak or missing
• Source-level tool only, no tree shaking = adequate (unusual; note the gap)

2.7 Circular Import Detection

Important: "installed" ≠ "configured" ≠ "enforced in CI". For each tool, verify actual usage:

• dependency-cruiser: check for config file (.dependency-cruiser.cjs, .dependency-cruiser.js, .dependency-cruiser.mjs), not just the package in devDependencies
• madge / dpdm / skott: check for a script in package.json that invokes them (e.g., "circular": "madge --circular src/")
• ESLint import/no-cycle: verify the rule is enabled in the ESLint config (rules section), not just that eslint-plugin-import is installed

Rating:

• Tool configured + runs in CI = strong
• Tool configured, not in CI = adequate
• Tool installed but no config / no script = weak
• Not detected = missing

2.8 Bundle Analysis (informational, not a gap)

• @next/bundle-analyzer, webpack-bundle-analyzer, rollup-plugin-visualizer, source-map-explorer
• Note: presence is good practice but absence is not a critical gap

2.9 Git Hooks & Pre-commit (informational - not scored)

Note if any of the following are present, but do NOT include this category in the scorecard or grade calculation. Some teams intentionally skip local hooks. If absent, mention it in the "Hardening Suggestions" section as an optional way to catch issues before they reach CI.

• Husky: .husky/ directory, husky in devDependencies
• lint-staged: lint-staged in package.json or .lintstagedrc*
• lefthook: lefthook.yml
• simple-git-hooks: simple-git-hooks in package.json

---

Phase 3: Testing Audit

3.1 Unit Testing

Search for:

• Test runner: Jest (jest.config.*), Vitest (vitest.config.*), Mocha, Jasmine, AVA
• Testing utilities: @testing-library/react, @testing-library/vue, @testing-library/angular, @testing-library/svelte
• Vitest browser mode: check for browser: { enabled: true } in vitest.config.* - also check for vitest-browser-react, vitest-browser-vue, vitest-browser-svelte packages. If Vitest browser mode is active, do NOT flag absence of @testing-library as a gap (browser mode provides native locators, user events, and component rendering).
• Other setups that don't need @testing-library:
  • Playwright component testing: @playwright/experimental-ct-react (or -vue, -svelte)
  • Cypress component testing: cypress/component directory or component in cypress config
  • Storybook interaction testing: @storybook/test with play functions
• Check for test scripts in package.json (test, test:unit)
• Search for test files: **/*.test.*, **/*.spec.*, **/__tests__/**
• Count test files vs source files to estimate coverage

3.2 Integration Testing

Definition for frontend: Integration testing = e2e-style tests (Playwright/Cypress) that run against a dev server, but without real network access - API calls are mocked via MSW, Playwright route() interception, or Cypress intercept(). This tests the full frontend stack (routing, rendering, state, UI) without depending on external services.

Detection:

• Playwright or Cypress config with webServer configuration (spins up a dev server)
• Combined with network mocking: msw, Playwright page.route() usage, Cypress cy.intercept() usage
• Files with integration in path or name

Note on MSW alone: MSW without a browser runner (Playwright/Cypress) = component-level network mocking. This contributes to unit testing depth, not integration testing. Only count MSW toward integration testing if paired with a browser-based test runner.

Other mocking tools: nock, miragejs - same rule applies: only count toward integration if paired with browser-based tests.

3.3 End-to-End Testing

• Playwright: playwright.config.*
• Cypress: cypress.config.*, cypress/ directory
• WebdriverIO: wdio.conf.*
• Check for e2e scripts in package.json
• For SSR: check if e2e tests cover hydration, streaming, server actions

3.4 Visual Regression Testing

• Chromatic, Percy, Applitools, BackstopJS, Loki
• Storybook: .storybook/ directory (enables visual testing)
• Storybook test runner, @storybook/test

3.5 Coverage Configuration

• Check for coverage configuration in test runner config
• Look for coverage thresholds
• Check if coverage reporting is in CI

3.6 SSR/SSG-Specific Testing

Only if framework uses server rendering:

• Tests for data fetching functions (getServerSideProps, getStaticProps, loader, load, server$)
• Tests for API routes / server actions
• Tests for middleware
• Hydration error testing
• Streaming SSR testing

---

Phase 4: CI/CD Pipeline Audit

Search for pipeline configurations:

4.1 CI Platform Detection

• GitHub Actions: .github/workflows/*.yml
• GitLab CI: .gitlab-ci.yml
• CircleCI: .circleci/config.yml
• Jenkins: Jenkinsfile
• Travis: .travis.yml
• Bitbucket: bitbucket-pipelines.yml
• Azure DevOps: azure-pipelines.yml
• Vercel: vercel.json (check for build commands, but note Vercel runs limited CI)
• Netlify: netlify.toml

4.2 Pipeline Coverage Check

For each detected CI config, check if these steps are included:

• [ ] Install dependencies
• [ ] Type checking (tsc --noEmit or equivalent)
• [ ] Linting (eslint, biome check)
• [ ] Formatting check (prettier --check, biome format --check)
• [ ] Unit tests
• [ ] Integration tests
• [ ] E2E tests
• [ ] Build verification
• [ ] Security audit (npm audit, snyk test)
• [ ] Coverage reporting
• [ ] Dead code check
• [ ] Bundle size check

4.3 Branch Protection (informational)

• Note if CODEOWNERS file exists
• Note if PR template exists (.github/pull_request_template.md)

---

Phase 5: Generate Report

Present findings in this exact structure:

Header

=== FRONTEND SHIFT-LEFT AUDIT ===
Framework: [detected]
Rendering: [SSR/CSR/SSG/ISR/Hybrid]
Language: [TS/JS]
Monorepo: [Yes/No]

Scorecard

Rate each area on a 4-level scale:

| Category | Status | Details | |----------|--------|---------| | Code Linting | [strong/adequate/weak/missing] | ... | | Type Safety | [strong/adequate/weak/missing] | ... | | Code Formatting | [strong/adequate/weak/missing] | ... | | Security Scanning | [strong/adequate/weak/missing] | ... | | Accessibility | [strong/adequate/weak/missing] | ... | | Dead Code Detection | [strong/adequate/weak/missing] | ... | | Circular Imports | [strong/adequate/weak/missing] | ... | | Unit Testing | [strong/adequate/weak/missing] | ... | | Integration Testing | [strong/adequate/weak/missing] | ... | | E2E Testing | [strong/adequate/weak/missing] | ... | | Visual Regression | [strong/adequate/weak/missing] | ... | | Coverage | [strong/adequate/weak/missing] | ... | | CI/CD Integration | [strong/adequate/weak/missing] | ... |

Scoring criteria:

• strong: Tool present, well-configured, integrated into CI, covers the framework's specific needs
• adequate: Tool present with basic config, may not be in CI or missing framework-specific checks
• weak: Partially set up, significant gaps in config or coverage
• missing: Not detected at all

Overall Grade

Calculate: count strong (3pts), adequate (2pts), weak (1pt), missing (0pts) across the 13 scored categories. Max = 39.

• A (33-39): Production-grade quality infrastructure
• B (26-32): Solid foundation, minor gaps
• C (20-25): Significant gaps that will cause issues at scale
• D (13-19): Major quality risks, needs immediate attention
• F (0-12): Minimal quality infrastructure

Critical Gaps

List the top 3-5 most impactful missing items, ordered by risk. For each:

• What's missing
• Why it matters (concrete risk)
• Recommended tool with one-line install command

Framework-Specific Recommendations

Based on the detected framework and rendering strategy, provide 2-3 targeted recommendations. Examples:

• Next.js SSR: "Add tests for getServerSideProps data fetching and error states"
• Nuxt SSR: "Add @nuxtjs/eslint-module for build-time linting"
• React CSR: "Add eslint-plugin-react-hooks rules for hooks dependency tracking"
• Angular: "Enable strictTemplates in angularCompilerOptions"

Quick Wins

List 3 things that can be added in under 30 minutes each, with install commands.

Hardening Suggestions (optional)

If git hooks (Husky, lint-staged, lefthook, simple-git-hooks) are NOT detected, include a brief suggestion here:

• Explain that adding pre-commit hooks can catch lint/format/type issues before they reach CI, saving pipeline time
• Note this is a team preference - some teams prefer not to block commits locally
• Provide install commands if the team wants to adopt it (e.g., npm i -D husky lint-staged && npx husky init)

If git hooks ARE detected, briefly note what they run (e.g., "Pre-commit: lint-staged runs ESLint + Prettier").

---

Rules

• Be factual. Only report what you actually find in the codebase. Never assume a tool is present without evidence.
• Check both root and workspace packages in monorepos.
• Distinguish between "installed but not configured" and "properly configured."
• For CI: read the actual workflow files, don't just check for their existence.
• If the repo is empty or has no package.json, report that and stop.
• Do not modify any files. This is a read-only audit.
• Keep the report concise but actionable. Every recommendation must include a concrete next step.
• "Installed" ≠ "configured" ≠ "enforced." Checking devDependencies alone is insufficient. For every tool, verify at least one of:
  • A config file exists for it
  • It appears in a package.json script
  • It's referenced in an ESLint/build config
  • It runs in CI
• Rating guide based on verification level:
  • strong: configured + enforced in CI
  • adequate: configured but not in CI, OR in CI but basic config
  • weak: installed but not configured, or configured but unused
  • missing: not detected at all