fix(deploy): rebuild when the data the bundle inlines changes

[datlechin]

/compare/postico is live right now promising "Postgres plus 17 other databases" on a page whose own table says 25 — an hour after #21 shipped the fix for exactly that, merged green and deployed successfully.

Why

resources/data/*.json reads like content and isn't. Every file in there is imported by a module under resources/js:

resources/js/data/comparisons.ts:1        import comparisonsData from '../../data/comparisons.json'
resources/js/data/databases.ts:1          import databasesData   from '../../data/databases.json'
resources/js/components/landing/database-grid.tsx:3  import gridData from '../../../data/database-grid.json'

Vite inlines them into the bundle at build time. But the deploy classified the whole directory as content, next to blog markdown:

if changed '^(resources/blog/|resources/data/|routes/)'; then
    CONTENT_CHANGED=true      # regenerates the sitemap, rebuilds nothing
fi

So the deploy log read:

now at 182a035
frontend=false composer=false php=false content=true
Deployed 182a035 (was bc795f1)

Green, sitemap regenerated, old bundle still serving the old data.

The test was defending the bug

DeployScriptTest asserted the wrong behaviour outright — resources/data/databases.json sat in the list of paths that must not trigger a rebuild. The bug had a passing test protecting it.

The fix

resources/data/ joins the front-end pattern. The replacement test derives its expectation from the imports themselves rather than naming files:

preg_match_all("#from '[^']*data/([a-z0-9-]+\.json)'#i", ...)

…so a new data file can't join the bundle and quietly miss the rebuild. It also covers everything else in the directory, so a not-yet-imported file still rebuilds rather than waiting for someone to notice it became bundled.

Note on the smoke test

The deploy that shipped this ran the server's pre-#22 copy of deploy.sh, so it printed server-rendered markup present rather than the new serving assets/app-XXX.js assertion. #22's build-identity check is on the server now and applies from the next deploy — it would not have caught this one anyway, since the assets were genuinely current; only their inlined data was stale.

Verification

pint:  passed
Tests: 168 passed (2152 assertions)   ← REQUIRE_SSR=1, no skips
bash -n scripts/deploy.sh: syntax OK