Skip to content

Configuration

All FE config comes through Vite env vars at build time, accessed via the typed ENV object in src/config/env.ts:

export const ENV = {
  API_URL:           import.meta.env.VITE_API_URL,
  BASE_URL:          import.meta.env.VITE_BASE_URL,
  APP_URL:           import.meta.env.VITE_APP_URL,
  APP_TYPE:          import.meta.env.VITE_APP_TYPE,
  USER_APP_TYPE:     import.meta.env.VITE_USER_APP_TYPE,
  ACCOUNT_MANAGER:   Number(import.meta.env.VITE_ACCOUNT_MANAGER),
  SUPER_ADMIN:       Number(import.meta.env.VITE_SUPER_ADMIN),
  ADMIN:             Number(import.meta.env.VITE_ADMIN),
  DEVELOPER:         Number(import.meta.env.VITE_DEVELOPER),
  DESIGNER:          Number(import.meta.env.VITE_DESIGNER),
  SOMELI_DEV_URL:    import.meta.env.VITE_SOMELI_DEV_URL,
};

Env vars

Var Required Used by
VITE_API_URL yes api.ts — Someli-admin-api base URL
VITE_BASE_URL optional (consumer not located; probably for cross-app links)
VITE_APP_URL optional links into customer app
VITE_APP_TYPE yes should be sent as base64 Apptype header — but api.ts hardcodes "admin-console" instead (see security.md F-2)
VITE_USER_APP_TYPE optional likely for impersonation flows
VITE_ACCOUNT_MANAGER, VITE_SUPER_ADMIN, VITE_ADMIN, VITE_DEVELOPER, VITE_DESIGNER yes role-ID constants used for permission gating
VITE_SOMELI_DEV_URL optional dev environment of customer app

The role IDs being env vars is unusual — normally these would be pinned in code. Doing so via env vars means a deploy can theoretically configure a different role for "SUPER_ADMIN" per environment. This is a source of drift risk: the backend's role_type values are not env-driven; the FE's are. Misalignment causes wrong-role bugs.

Recommendation: hardcode the role IDs as a const enum Role { SUPER_ADMIN = 1, ADMIN = 2, ... } shared with the backend (via a small types package).

.env files

The repo's .gitignore should exclude .env, .env.local, etc. — verify. No .env* file is committed at audit time. There is no .env.example — a new engineer cloning the repo doesn't know what to fill in. Add an .env.example with placeholder values.

Vite config

vite.config.ts:

export default defineConfig(({ mode }) => ({
  server: {
    host: "::",
    port: 8080,
    allowedHosts: ["admin.someli.ai"],
    fs: { strict: true, deny: ['.env', '.git'] },
    hmr: { overlay: false },
  },
  plugins: [
    react(),
    mode === 'development' && componentTagger(),  // lovable-tagger
  ].filter(Boolean),
  resolve: {
    alias: { "@": path.resolve(__dirname, "./src") },
  },
}));

Notes:

  • host: "::" binds IPv6 (and IPv4 dual-stack on most OSes). Fine for dev.
  • port: 8080 is the dev port; production hosting is unknown
  • allowedHosts: ["admin.someli.ai"] — only useful if Vite is reverse-proxied through admin.someli.ai during dev (an unusual setup). Probably leftover.
  • fs.strict + fs.deny — sensible
  • hmr.overlay: false — disables error overlay; flag as a dev-UX downgrade
  • lovable-tagger only in dev mode

TypeScript config

Three tsconfigs (tsconfig.json, tsconfig.app.json, tsconfig.node.json) — the Vite-React template default. Verify strict: true is set in tsconfig.app.json (many bootstrapped projects ship with strict: false).

Build mode flag

The build:dev script (vite build --mode development) lets you produce a "development build" — useful for staging environments that want source maps and unminified code. Confirm the deployment uses build:dev for staging and build for prod.

Hosting config

There is no in-repo hosting config (no vercel.json, netlify.toml, firebase.json, _redirects, _headers). The hosting layer is owned outside the repo. To deploy the SPA, the hosting target needs:

  • Serve the contents of dist/ as static files
  • Fallback to dist/index.html for any unrecognised path (SPA routing)
  • Cache dist/assets/* aggressively (filenames are hashed)
  • Cache dist/index.html short-TTL or no-cache
  • Inject CSP, X-Frame-Options, Referrer-Policy headers (per security.md)

A short nginx config in this repo (similar to someli-platform/nginx.conf) would document the deployment intent. Recommendation: commit one.