Skip to content

Build & Deploy

Build

{
  "scripts": {
    "dev":       "vite",
    "build":     "vite build",
    "build:dev": "vite build --mode development",
    "lint":      "eslint .",
    "preview":   "vite preview"
  }
}
  • npm run dev → Vite dev server on port 8080
  • npm run build → dist/ with hashed asset filenames
  • npm run build:dev → dist/ but with development mode flags (sourcemaps, no minification)
  • npm run preview → serves dist/ for local QA

Typical local build time: ~10-20 seconds (Vite is fast).

Build artefact

dist/: 

dist/
├── index.html
└── assets/
    ├── index-<hash>.js
    ├── index-<hash>.css
    └── ... (chunks, images)

Vite hashes asset filenames for cache-busting. index.html should be cached with a short TTL or no-cache; everything in assets/ can be cached forever (immutable).

Source maps

By default, Vite emits source maps only in build:dev mode. Production builds (npm run build) do not emit source maps unless build.sourcemap: true is set in vite.config.ts. Currently not set, so production has no source maps.

Trade-off: - Without source maps: smaller deploy; production errors are unreadable stack traces - With source maps + Sentry upload: bigger deploy, but production errors are debuggable

When Sentry is added (see observability.md), enable source maps + upload them at build time + serve them from the same origin only when needed (not as public files).

Deploy artefacts in the repo

Artefact Present?
Dockerfile ❌
Jenkinsfile ❌
.github/workflows/ ❌
nginx.conf ❌
vercel.json / netlify.toml / _redirects / _headers ❌
Deploy script (push.sh, deploy.sh) ❌

No deploy infrastructure in this repo. The hosting strategy is owned outside the repo. From the vite.config.ts allowedHosts: ["admin.someli.ai"] setting, the production host is admin.someli.ai. Who/what deploys to that hostname is unclear from the repo alone.

Probable production setup (verify)

Working assumption:

  1. CI (somewhere — Jenkins box? GitHub Actions in another repo?) checks out this repo, runs npm ci, npm run build
  2. The contents of dist/ are uploaded to a static host (S3 + CloudFront? Lightsail nginx? Vercel?)
  3. nginx (or CDN) is configured to:
  4. Serve dist/index.html for / and any unrecognised path (SPA routing)
  5. Serve dist/assets/* with Cache-Control: public, max-age=31536000, immutable
  6. Set CSP, X-Frame-Options, Referrer-Policy headers
  7. Terminate TLS

None of this is documented in-repo. Recommendation: commit either a Dockerfile + nginx.conf (matching the pattern used by someli-platform) or a CI workflow file (matching someli-api's GitHub Actions pattern).

For a 6-page internal admin tool with low traffic, simplest options:

Option A — S3 + CloudFront

  • Vite build → upload dist/ to S3
  • CloudFront distribution with origin = S3 bucket
  • Error response: 404 → /index.html with 200
  • One CloudFront invalidation per deploy
  • Simple GitHub Actions workflow with aws-actions/configure-aws-credentials + aws s3 sync

Option B — Vercel / Netlify

  • Connect repo to Vercel/Netlify
  • Build command: npm run build
  • Output dir: dist/
  • Custom domain: admin.someli.ai
  • Zero hand-rolled deploy code

Option C — nginx on Lightsail (consistent with other repos)

  • Dockerfile: FROM nginx:alpine → COPY dist/ /usr/share/nginx/html/
  • nginx.conf: SPA fallback + cache headers
  • Jenkins pipeline matching someli-api/Jenkinsfile

The team's existing pattern is Lightsail + Jenkins (Option C); adopting that here would be the least-novel path.

Rollback

No documented mechanism. With static hosting, rollback is "redeploy the previous build". Recommend:

  1. Tag every deploy with the git SHA
  2. Keep the last N builds on the host
  3. Document the rollback runbook (one paragraph) in this file once a deploy mechanism exists

Preview deployments

None at audit time. If migrating to Vercel/Netlify (Option B), preview deploys per PR come for free.

Environment differentiation

vite build vs vite build --mode development is the only differentiation. The mode flag selects .env.production vs .env.development — Vite reads these by convention. To target a third environment (e.g., UAT), would need vite build --mode uat + .env.uat.

The customer FE (someli-platform) uses Jenkins env-var injection rather than Vite mode. This repo could either: - Stick with Vite modes (simplest) - Adopt Jenkins env injection (consistent with the platform)

Pick one when committing a CI workflow.

Branch model

No documented branch model in this repo. Assume the platform default: feature → dev → uat → main.

The HEAD commit at audit time is cfa40c1 on main (2026-01-13). Commit history shows small CustomerService fixes.