Jesse
ea012f1329
Submodule pin moves to v0.5.2, which carries the working splash-page
multiplayer door and the GET /api/health probe behind it.
The interface goes back to serving `/` — the splash, which is the front
door to all three ways to play. It pointed at /play.html only because the
splash's multiplayer door was hardcoded to "Coming soon", making the front
page a dead end on a real server; v0.5.2 removes the reason for the
workaround. The splash now probes /api/health on load, so served from here
it opens the lobby and served as a plain static site it says plainly that
it needs a server.
The package version was wrong and is corrected: 1.0.0:0 -> 0.5.2:0. That
1.0.0 was the scaffold's placeholder, left in by mistake — versions.md's
consistency checklist requires the upstream half to match the bundled tag,
which is what makes "bump the pin, bump the version" one mechanical action
rather than a judgement call. No historical version file is needed: the
placeholder carried no migration and was never published anywhere.
The correction is a downgrade in ExVer terms, so StartOS refused to install
over the existing copy ("uninit target range `!` is unsatisfiable"). The
installed package was therefore removed and reinstalled — checked first
that the volume held only an auto-generated join secret and no games. Two
consequences, both one-time and both recorded in UPDATING.md: the join
secret is regenerated, and the host's public domain binding was dropped
with the uninstall and has to be re-added.
Verified on phoenix.local: builds as v0.5.2:0, installs, starts, and serves
/api/health 200 with the right body; the splash carries all three doors
including a live ./play.html?lobby, no "Coming soon" anywhere, all three
ids the probe addresses present, and #lobby rendering on play.html?lobby.
34 lines
1.5 KiB
TypeScript
34 lines
1.5 KiB
TypeScript
import { i18n } from './i18n'
|
|
import { sdk } from './sdk'
|
|
import { uiPort } from './utils'
|
|
|
|
// One interface: the server serves the browser client, the lobby/intent HTTP API, and the SSE
|
|
// game stream all from this single port (deployment.md's same-origin rule in the game repo —
|
|
// baking in a second origin would break relative URLs). type: 'ui' is a label the client is
|
|
// meant for a browser; it does not stop the same port from also carrying the API calls that
|
|
// client makes back to itself.
|
|
export const setInterfaces = sdk.setupInterfaces(async ({ effects }) => {
|
|
const uiMulti = sdk.MultiHost.of(effects, 'ui-multi')
|
|
const uiMultiOrigin = await uiMulti.bindPort(uiPort, { protocol: 'http' })
|
|
const ui = sdk.createInterface(effects, {
|
|
name: i18n('Multiplayer Table'),
|
|
id: 'ui',
|
|
description: i18n('Create or join a game, and play in the browser'),
|
|
type: 'ui',
|
|
masked: false,
|
|
schemeOverride: null,
|
|
username: null,
|
|
// The splash at `/`, which is the front door to all three ways to play: solitaire, the
|
|
// replay viewer, and multiplayer. Its multiplayer door probes `/api/health` on load, so
|
|
// served from here it opens the lobby, and served as a plain static site it says plainly
|
|
// that it needs a server. This briefly pointed at `/play.html` instead, back when that door
|
|
// was hardcoded to "Coming soon" and the splash was a dead end on a real server.
|
|
path: '',
|
|
query: {},
|
|
})
|
|
|
|
const uiReceipt = await uiMultiOrigin.export([ui])
|
|
|
|
return [uiReceipt]
|
|
})
|