Files
star-map/e2e
SenrokaiandClaude Opus 5 f14e252b19 Name the neighbours that have a name, before the ones that only have a number
The neighbour ring exists to say where you are. Since the catalogue refresh it
has been spending one of its four places in Sol on "Gaia DR3 5853498713190525696"
-- a nineteen-digit survey id for the star printed beside it as Proxima
Centauri, the same star twice -- and that duplicate row pushed Barnard's Star
off the ring altogether. 91.9% of the refreshed catalogue is named that way.

Named stars now come first, and survey designations fill in only where fewer
than four named ones are in reach. The line between the two is the one the
catalogue format already draws: a name is a designation when it is what the
star's source would generate for it. Judged by the prefix rather than by
rebuilding "prefix id" from the row, because the number after "Gaia DR3" is the
survey's own id, which the 32-bit row id cannot hold -- a round trip through
the id would have called every one of those stars named.

The preference lives on the index as `nearestPreferring`: the preferred pass
exhausts the search before the fill runs, so a named star is never outranked by
a nearer unnamed one. That is the whole point of asking.

The end-to-end spec names Barnard's Star again, on purpose. The four nearest
named stars to the Sun are a fact about space, not about which catalogue was
refreshed last, and without this change that is exactly the label that
vanished -- checked by running the spec with the preference stashed: it fails
on that line, and passes with it back.

npm test 609/609, npx playwright test 16/16 under CI=true --workers=2.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014fcUfL82nvyh9VebX1Fz6w
2026-08-27 20:06:04 +02:00
..
@
2026-08-03 16:50:10 +02:00

End-to-end tests (Playwright)

These tests run the real Angular dev server in a real Chromium browser, covering interactions that unit/component tests (under src/**/*.spec.ts, run via npm test) can only approximate under jsdom — most importantly the galaxy↔system camera-flight transitions (real WebGPU/ WebGL2 initialization + raycaster picking) and cross-view search navigation.

Running

npm run e2e             # headless run against a freshly started dev server
npx playwright test --ui # interactive UI mode
npx playwright show-report

playwright.config.ts starts npm run start -- --port=4300 automatically and waits for it to respond before running the suite (webServer.reuseExistingServer is true outside CI, so an already-running ng serve on port 4300 is reused instead of starting a second one). Port 4300 is used instead of the Angular CLI's conventional 4200 to avoid colliding with an unrelated server a developer might already have running there.

Notes

  • The Sun (Sol) is always placed at the coordinate-system origin (x=0,y=0,z=0), which is exactly where the default galaxy-view camera looks. camera-flight.spec.ts relies on this to reliably click-select it by clicking the center of the canvas, without needing pixel-perfect knowledge of the star field's on-screen layout.
  • Data (bootstrap fetch of stars.bin/stars-index.json/bodies.json/exoplanets.json/ deepsky.json) loads asynchronously after the page loads, so tests poll (re-click/re-check) rather than assume the scene is interactive immediately after page.goto().
  • deepsky.json is the one dataset the scene treats as optional: it only feeds the decorative backdrop, so a failure to load it is logged and the star field comes up regardless.