Skip to content
Nexa Engineering Handbook

Example: `nexa-web`

Verified test stack

Section titled “Verified test stack”

Recent nexa-web work establishes Vitest as the unit-test runner:

  • PR #622 adds Vitest, @testing-library/react, @testing-library/user-event, and jsdom, with test, watch, and coverage scripts.
  • PR #684 uses Vitest for unit tests and includes custom .mjs browser flows for E2E behavior.
  • Jest is not part of the Nexa Web standard.

Repository responsibilities

Section titled “Repository responsibilities”

nexa-web owns its source, Vitest tests, package lock, Sonar project, multi-stage Bookworm Slim Dockerfile, and minimal caller workflow. The common nexa-ci repository owns orchestration and scanner versions.

name: CI
on:
  pull_request:
    branches: [develop, main, 'release/**']
  push:
    branches: [develop, main, 'release/**']
    tags: ['v*.*.*']


jobs:
  ci:
    uses: dataready-ai/nexa-ci/.github/workflows/react-ci.yml@v1
    with:
      node-version: '24'
      test-command: npm run test:unit
      coverage-command: npm run test:coverage
      image-name: nexa-web
      docker-context: .
      dockerfile: Dockerfile
      docker-runtime-target: runtime
      ecr-repository: aws-iac-nexa-web
      acr-repository: nexa-web
      spcs-repository: NEXA_WEB_REPO
      sonar-project-key: nexa-web
    secrets: inherit

Required source-CI capabilities

Section titled “Required source-CI capabilities”

The repository exposes stable commands for formatting, linting, type checking, Vitest unit/component execution, watch mode, and coverage. Vitest coverage is emitted in LCOV for SonarQube. Testing Library is used for user-observable component behavior.

Post-deployment boundary

Section titled “Post-deployment boundary”

Custom .mjs browser flows and future Playwright/Allure suites run against a deployed lower environment. API and contract tests also run post-deployment. They provide runtime confidence but do not replace the Vitest source-CI merge gate.

Container standard

Section titled “Container standard”

The build stage uses the approved Node 24 Bookworm Slim base; the Nginx serving stage uses its approved runtime base. The final image contains only compiled assets or the approved server runtime, runs non-root where supported, and contains no build credentials or testing toolchain.