pm2 for BOTH, development included. A `bun dev` started in a terminal dies with the terminal, and nobody can tell whether it is running without finding the window it was started in. Under pm2 the two are the same kind of thing — a named process with a status, an uptime and a log, startable from here and inspectable from anywhere. The cost is that development stops printing to a console somebody is watching, which is what `pm2 logs fofos-dev` is for; the process names are in the panel so nobody has to guess them. This plugin owns exactly two names, `fofos-dev` and `fofos-prod`, and every command is built from that pair and from nothing a caller supplies. No request can stop, restart or delete another process on the machine. That matters more than usual here: Officer's own processes share this pm2 daemon, and a plugin able to name any of them would be a way to take the host down through a web form. Start is really a replace — delete, then start. Not `restart`: it fails on a process that has never existed, and on one that has it reuses the environment it was started with, so a port or database changed here would be saved, displayed, and not in effect. That is an hour of somebody's debugging. The environment is assembled here because this plugin is what knows the ports and the database names, and it is handed to pm2 through the invoking command's own environment — pm2 has no flag for it; `--env` names a block in an ecosystem file. The site reads .env files first and the environment last, so this fills what is absent rather than overriding what somebody wrote down. Ports have no default. It is the one setting where a plausible guess is worst: it binds, the site appears to work, and it is quietly answering on a port another service wanted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
80 lines
3.5 KiB
TypeScript
80 lines
3.5 KiB
TypeScript
import { useSearchParams } from 'react-router';
|
|
import { DEFAULT_SECTION, isSectionKey, sectionFor, sectionOpen, type SectionKey } from './sections';
|
|
import { AdministrationPanel } from './AdministrationPanel';
|
|
import { ServersPanel } from './ServersPanel';
|
|
import { MediaPanel } from './MediaPanel';
|
|
import { MessagesPanel } from './MessagesPanel';
|
|
import { PlannedSection } from './PlannedSection';
|
|
import { useReady } from './useReady';
|
|
|
|
/**
|
|
* The right column: whichever section the nav has selected.
|
|
*
|
|
* It reads `?section=` from the URL rather than being handed it — the two panels are siblings in a
|
|
* workspace and neither owns the other.
|
|
*
|
|
* ── There used to be a `?config=1` ──
|
|
*
|
|
* The connection form was an overlay reached from a link in this header, because it was not one of the
|
|
* sections. Now it IS one — Administration — so the overlay is gone and so is the link. A second route
|
|
* to the same screen is a second thing to keep correct, and the two disagreed the moment a section was
|
|
* selected underneath a form that covered it.
|
|
*
|
|
* ── Not ready means Administration, whatever the URL says ──
|
|
*
|
|
* The gate is `useReady`, shared with the nav so the two cannot disagree. Enforced HERE and not only
|
|
* there, because the nav can only decline to offer a link — `?section=gallery` typed into the address
|
|
* bar, or a bookmark from before the connection was forgotten, arrives without going through it. A
|
|
* nav that hides a door is a courtesy; this is the lock.
|
|
*/
|
|
|
|
/**
|
|
* Which component renders which section.
|
|
*
|
|
* A map rather than a conditional on `built`. The version of this that read
|
|
* `built ? <MessagesPanel/> : <Planned/>` was correct only while exactly one section existed — the
|
|
* second one to be finished would have rendered Messages under its own name, which is the kind of bug
|
|
* that looks like a data problem for an hour. A key with no entry here falls through to Planned, so
|
|
* marking a section `built` in sections.ts without writing its panel fails visibly rather than
|
|
* silently showing somebody else's.
|
|
*/
|
|
const PANELS: Partial<Record<SectionKey, () => React.JSX.Element>> = {
|
|
messages: MessagesPanel,
|
|
administration: AdministrationPanel,
|
|
servers: ServersPanel,
|
|
media: MediaPanel,
|
|
};
|
|
|
|
export const DetailPanel = () => {
|
|
const [params] = useSearchParams();
|
|
const raw = params.get('section');
|
|
const selected: SectionKey = isSectionKey(raw) ? raw : DEFAULT_SECTION;
|
|
|
|
const { ready, rootSet, loading } = useReady();
|
|
|
|
if (loading) {
|
|
return <div className="flex size-full items-center justify-center p-6 text-sm text-muted-foreground">Loading…</div>;
|
|
}
|
|
|
|
/*
|
|
Not ready, so Administration regardless of what the URL asked for. The header then NAMES it, which
|
|
is the part the old overlay could not do: the form used to appear under whichever row happened to
|
|
be highlighted, so it read as that section being broken rather than as one step not done yet.
|
|
*/
|
|
/*
|
|
A section that cannot be opened sends you to Administration, because that is where every requirement
|
|
is satisfied. Asked per section rather than by one flag: Media is reachable the moment a root
|
|
location exists, long before fofos is connected.
|
|
*/
|
|
const wanted = sectionFor(selected);
|
|
const current = sectionOpen(wanted, { ready, rootSet }) ? wanted : sectionFor('administration');
|
|
|
|
const Panel = current.built ? PANELS[current.key] : undefined;
|
|
|
|
return (
|
|
<div className="flex size-full flex-col overflow-hidden">
|
|
<div className="min-h-0 flex-1">{Panel ? <Panel /> : <PlannedSection section={current} />}</div>
|
|
</div>
|
|
);
|
|
};
|