Frontend engineering: quality gates and repeatable delivery

Frontend engineering is not a list of tools. Its purpose is to shorten the feedback loop from discovering a problem to locating its cause and verifying the fix. A mature project should make local and CI behavior consistent and answer what a release contains, how it was validated, and how it can be rolled back.

An explainable pipeline

Pull request gates
  ├─ frozen install / dependency integrity
  ├─ lint + format check
  ├─ typecheck
  ├─ unit / component tests
  └─ production build

Main branch and release
  ├─ full tests + critical E2E flows
  ├─ artifact, dependency, and security analysis
  ├─ immutable artifact + version manifest
  ├─ canary and health checks
  └─ metric observation / rollback

Pull request feedback should be fast; the main branch can run broader checks. A failure log should identify the task, file, and artifact—not only report exit code 1.

Dependencies and lockfiles

Commit one lockfile and use a clean or frozen install in CI. Multiple package managers can produce different dependency graphs and undermine repeatability. Before an upgrade, review the changelog, Node engine, and breaking changes, then validate with type checking, tests, a production build, and a bundle diff.

Configuration and secrets

Anything included in a frontend artifact is visible to users. A VITE_ prefix is not secret storage. Expose only public configuration, keep server credentials out of the browser bundle, and validate the schema of runtime configuration.

Testing based on risk

• Pure functions, stores, and composables: fast unit tests for transitions and boundaries.
• Components: user-visible behavior, error states, permission states, and accessibility.
• E2E: a small set of critical login, purchase, and publishing flows with isolated data.

Coverage is evidence, not the objective. A permission state machine with meaningful branch tests is more valuable than snapshots that only mirror implementation details.

Release and rollback

Build a commit once and promote the same artifact through environments. HTML and hashed chunks need compatible cache policies; a rollback must preserve the old chunks referenced by the restored HTML.

Engineering success should appear as less version drift, faster feedback, and more controllable failures—not a longer configuration file.