Files
Stirling-PDF/frontend
ConnorYoh c19d56de22 PAYG usage card: review follow-ups (avg/PDF, empty-state, unique wording) (#6967)
Small follow-up to #6957 addressing the three non-blocker findings from
its review. **Draft / stacked on #6957** — the diff shows #6957's
changes until it merges, then auto-narrows to just these 5 files. Mark
ready + rebase onto `main` once #6957 lands.

### 1. avg-per-PDF no longer blends unsynced units over synced-only docs
`avgCostMinor` now divides **synced** units (`spendUnitsThisPeriod`) by
synced docs, so numerator and denominator cover the same population.
Combined-billing `pendingUnits` (units-only, no doc count) previously
inflated the average for linked-instance teams. The "meter units" figure
still shows synced+pending (total current usage) — only the *average* is
synced-only.

### 2. Empty-state: unsynced-only reads cleanly
When `docs == 0` but there are pending meter units (combined-billing,
nothing synced yet), the card showed a bare **"0 PDFs"** headline with a
count-less summary and no split. It now shows a **"{n} meter units
pending sync from linked instances"** note instead. New `unitsPending`
i18n key + a `UnsyncedOnly` story. (Only reachable on the
combined-billing path; pure-SaaS teams are unaffected.)

### 3. uniquePdfs wording is now accurate
`document_fingerprint` is a hash of a charge's whole **input set**, so
the same file reused across *different* groupings (standalone, then
later in a merge `{A,B}`) counts per grouping — a close approximation of
"unique PDFs", exact for the single-input common case. Softened the FE
type doc + the `WalletLedgerEntry.document_fingerprint` javadoc to say
so (no behaviour change; counting model unchanged).

### Verification
FE typecheck / test / lint / format all clean; `:saas:compileJava`
green. No behaviour change beyond #1 (avg) and #2 (empty-state copy); #3
is doc-only.
2026-07-20 13:51:55 +00:00
..
2026-04-27 11:35:50 +01:00
2026-05-22 13:40:34 +01:00

Frontend

All frontend commands are run from the repository root using Task:

  • task frontend:dev — start Vite dev server (localhost:5173)
  • task frontend:build — production build
  • task frontend:test — run tests
  • task frontend:test:watch — run tests in watch mode
  • task frontend:lint — run ESLint + cycle detection
  • task frontend:typecheck — run TypeScript type checking
  • task frontend:check — run typecheck + lint + test
  • task frontend:install — install npm dependencies

For desktop app development, see the Tauri section below.

Layout

frontend/ is a workspace containing one or more apps. Today it holds the PDF editor under frontend/editor/; new apps (the developer portal, etc.) will sit alongside it as siblings. Shared tooling — package.json, node_modules, .storybook/, ESLint, Prettier — lives at frontend/ so every app installs once and lints with the same config.

Environment Variables

The editor's environment variables live in committed .env files at frontend/editor/:

  • .env — used by all builds (core, proprietary, and as the base for desktop/SaaS)
  • .env.desktop — additional vars loaded in desktop (Tauri) mode
  • .env.saas — additional vars loaded in SaaS mode

These files contain non-secret defaults and are checked into Git, so most dev work needs no further setup.

To override values locally (API keys, machine-specific settings), create an uncommitted sibling editor/.env.local / editor/.env.desktop.local / editor/.env.saas.local. Vite automatically layers these on top of the committed files.

Docker Setup

For Docker deployments and configuration, see the Docker README.

Tauri

All desktop tasks are available via Task. From the root of the repo:

Dev

task desktop:dev

This ensures the JLink runtime and backend JAR exist (skipping if already built), then starts Tauri in dev mode.

Build

task desktop:build

This does a full clean rebuild of the backend JAR and JLink runtime, then builds the Tauri app for production.

Platform-specific dev builds are also available:

task desktop:build:dev           # No bundling
task desktop:build:dev:mac       # macOS .app bundle
task desktop:build:dev:windows   # Windows NSIS installer
task desktop:build:dev:linux     # Linux AppImage

You can also run JLink steps individually:

task desktop:jlink          # Build JAR + create JLink runtime
task desktop:jlink:jar      # Build backend JAR only
task desktop:jlink:runtime  # Create JLink custom JRE only
task desktop:jlink:clean    # Remove JLink artifacts

Clean

task desktop:clean

Removes all desktop build artifacts including JLink runtime, bundled JARs, Cargo build, and dist/build directories.