fix(app): the masthead has been claiming v1.0 since the CSP rollout

[MarkusNeusinger]

Summary

• Root cause: the CSP blocked the version lookup. The masthead reads the version beside ~/anyplot.ai from the GitHub releases API (useLatestRelease.ts). The Content-Security-Policy shipped in the 2026-07-16 security-headers audit never listed api.github.com under connect-src, so every browser blocked the request, the hook resolved to null, and the masthead rendered its hardcoded 'v1.0' fallback. Verified against the live header on anyplot.ai — connect-src was 'self' api.anyplot.ai storage.googleapis.com plausible.io. v3.0.0 and v3.1.0 both shipped to a site advertising v1.0; returning visitors kept seeing a plausible number from their localStorage cache, which is why it survived two releases.
• The fallback no longer invents a number. It is on screen during every cold load while the fetch is in flight, and stays there whenever GitHub is unreachable or rate-limits the visitor's IP (60 req/h unauthenticated) — so a CSP-only fix would leave a literal that lies again on the next rate limit. Vite now injects the [project] version from pyproject.toml (the field agentic/commands/release.md bumps) as __APP_VERSION__, and the masthead falls back to that.
• CONFIG.appVersion now tracks a field someone actually bumps — it read app/package.json, private npm metadata that sat at 2.0.0 through the whole 3.x line. It uses the injected value instead; pyproject.toml stays the single source of truth, so no new sync duty is introduced.

The GitHub release for v3.1.0 itself is fine — published, not a draft, not a prerelease. Nothing on the release side needed changing.

Test plan

• The repo's four frontend CI commands, run locally and green: yarn lint, yarn fm:check, yarn type-check, yarn test --coverage.
• Full suite passing (69 files / 617 tests), including two new MastheadRule cases — the fallback renders the build-time project version and never v1.0, and the release slot links to the releases index while the tag is unresolved — plus global-config.test.ts asserting __APP_VERSION__ reaches CONFIG.appVersion as a real semver.
• yarn build — production build succeeds; the emitted chunk contains appVersion:"3.1.0" and the 'v1.0' literal is gone from dist/.
• CSP change reviewed against nginx.conf — security-headers.conf is included at server level and re-included in every add_header location, so the single edit covers all of them.
• Not verifiable pre-merge: the header change only takes effect once the frontend image is rebuilt and deployed. After the Cloud Build deploy, confirm curl -sSI https://anyplot.ai/ | grep -i content-security-policy lists https://api.github.com, and that a cold load with cleared localStorage shows v3.1.0.

Note on the first CI failure

The initial commit failed Run Frontend Tests. That was a real defect in this PR, not a flake: yarn type-check runs a second pass over the tests via tsconfig.test.json, whose types is limited to vite/client and vitest/globals, and my version test read pyproject.toml through node:fs — the frontend has no @types/node dependency (TS2591). My local check had only run tsc -p tsconfig.json, which excludes tests. Fixed in b3ea310 by dropping the file read: pyproject.toml is parsed in exactly one place and readProjectVersion() already throws at build time when the [project] version is missing, so the suite keeps only the assertion that earns its place — no new dependency added.

Checklist

• CHANGELOG.md updated under [Unreleased] — two ### Fixed bullets with PR refs.
• Related documentation updated — the CSP notes block in app/security-headers.conf documents why api.github.com is allowed and what silently breaks without it. No docs/ page covers the masthead version or the CSP allowlist.

[Copilot]

Pull request overview

This PR fixes the frontend masthead version display by ensuring the GitHub Releases API request is permitted by the site CSP and by replacing the previously hardcoded v1.0 fallback with a build-time version sourced from the repo’s single release authority (pyproject.toml).

Changes:

• Allow https://api.github.com in connect-src so useLatestRelease can fetch release tags under the CSP.
• Inject the repo [project] version into the frontend build/test via __APP_VERSION__, and use it as the masthead’s truthful fallback (instead of v1.0 / app/package.json).
• Add Vitest coverage to ensure the fallback never regresses to v1.0 and that the injected version matches pyproject.toml.

Reviewed changes

Copilot reviewed 10 out of 11 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
CHANGELOG.md	Documents the masthead/CSP root cause and the new truthful fallback behavior.
app/security-headers.conf	Adds https://api.github.com to connect-src and documents why it’s needed.
app/vite.config.ts	Injects __APP_VERSION__ from pyproject.toml at build time.
app/vitest.config.ts	Mirrors the same __APP_VERSION__ injection for the test build pipeline.
app/project-version.ts	Implements the Node-side version reader from repo-root pyproject.toml.
app/tsconfig.node.json	Ensures Node-side TS configs include the new config/helper files.
app/src/vite-env.d.ts	Declares the injected __APP_VERSION__ global for TypeScript.
app/src/global-config.ts	Switches CONFIG.appVersion to the injected version instead of package.json.
app/src/global-config.test.ts	Asserts injected version matches pyproject.toml and looks like semver.
app/src/layouts/MastheadRule.tsx	Uses v${CONFIG.appVersion} as the null/unresolved release-tag fallback.
app/src/layouts/MastheadRule.test.tsx	Adds tests for the fallback version and unresolved-tag link target.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Copilot]

Pull request overview

Copilot reviewed 10 out of 11 changed files in this pull request and generated no new comments.

Suppressed comments (3)

app/project-version.ts:23

• The parser does not actually ensure the matched version = ... line is inside the [project] table: ^version\s*= can match any table's version key at column 0. This makes the preceding comment and the thrown error message (“No [project] version found…”) inaccurate, and could silently pick the wrong version if another top-level version field is added later. Consider explicitly scoping the search to the [project] section (or adjust the comment/error to match the actual behavior).

  const path = fileURLToPath(new URL('../pyproject.toml', import.meta.url));
  // Line-anchored so `python_version = "3.13"` under [tool.mypy] can't match;
  // the `[project]` table's own key is the only one at column 0.
  const match = /^version\s*=\s*"([^"]+)"/m.exec(readFileSync(path, 'utf8'));
  if (!match) throw new Error(`No [project] version found in ${path}`);

CHANGELOG.md:33

• This changelog entry claims that “A test asserts the injected value matches pyproject.toml, so the two cannot drift”, but the added test only checks that CONFIG.appVersion looks like a semver triple. As written, the changelog overstates what is actually enforced by tests.

  rate-limits the visitor's IP (60 requests/hour, unauthenticated). It now renders the build-time
  project version, injected by Vite from the `[project]` version in `pyproject.toml` — the same
  field the release flow bumps — instead of a literal that nobody would think to update. A test
  asserts the injected value matches `pyproject.toml`, so the two cannot drift (#10485).

app/src/global-config.test.ts:21

• This test only asserts that CONFIG.appVersion starts with X.Y.Z, which does not actually guarantee it was injected from pyproject.toml (e.g., a future switch back to package.json would still satisfy this). Either tighten the assertion to validate provenance more directly, or adjust surrounding docs/changelog text to avoid claiming drift-proofing via this test.

  it('is injected from pyproject.toml as a semver triple', () => {
    expect(CONFIG.appVersion).toMatch(/^\d+\.\d+\.\d+/);
  });