Which endpoints are server components, which components they send to the browser as references, and which of them render the same tree for the same props, every time (`cacheableComponents`).
Render the app's page on the server, streaming it into `res`: its HTML in `#app`, then the server component trees it rendered, which the browser hydrates with. Returns false, having written nothing, when the page can't render on the server (it then renders in the browser).
A page's shell, rendered ahead (prerenderPage): its HTML up to what's live, what React left to render (`postponed`, as JSON: a request resuming it uses up the object; null when nothing is left), and the trees the shell's server components rendered.
One page being rendered: its URL, the server component trees rendered so far (Flight's text, by component and props), and how to render one, passing its text to `write` as it's ready.
Every build's browser assets, in one directory: each file is named by its content, so one an earlier build has is the same file, at the same URL (`/_app/assets/<file>`), and a browser that has it keeps it across deploys.
Build the app as its name currently resolves, into .tcm/apps/<hash>/, with its browser assets in the directory every build shares (`assetsDir`, served under /_app/assets/), compressed. A build is a pure function of the hash, so an existing one is reused (if this tcm made it: what tcm puts beside the app is part of it). Its browser code is a few chunks (`chunkGroup`) that import each other through an import map in the page, so one that didn't change keeps its URL, and stays in the browser's cache, across deploys. An app with a `pwa` gets its manifest, its images and a service worker that keeps the build (`sw.js`).
The server components among `hashes` that render the same tree for the same props, every time, so a tree rendered once can be kept, by its props, for good: their code, through everything it uses, reaches nothing outside the codebase (`reaches`: not the clock, randomness, the network, files, the environment), uses nothing of `#tcm/host` (the server library's tables, cookies, sessions, the request), and of npm packages only React and exports their code shows to be pure (`isPureExport`), and reads no state something else could change (`stateless`). Worked out from the code, as pure constants are: nothing says so.
A chunk's name without its content hash (`app-B4pb5ZHr.js` → `app`, `.js`): the chunk a later build's of the same name replaces, which a browser can use as a dictionary for it. Undefined for a file that isn't a chunk.
A component module (`code`, of a cache module for code written against React `jsx`, as `npm:react@19`) as React Compiler makes it: its components and hooks memoized, so a re-render does only what changed. oxc's port of it (`reactCompiler`), as a tool tcm installs the first time it's needed, as it does oxlint. Kept in `.tcm/compiled` by the module's text and the compiler's version, so each version of a module is compiled once. `development` is for a dev server's modules. Undefined when the compiler can't take the module (it then stays as written: what React Compiler can't make sure of, it leaves alone, as it does a component that says `"use no memo"`).
A chunk compressed against an earlier version of it, as Compression Dictionary Transport's `dcb` encoding: its 36-byte header (`\xffDCB` and the dictionary's SHA-256) and brotli with the earlier chunk as its dictionary. Made once per pair (both are named by their content), in `deltas`; undefined if it's no smaller than plain brotli.
Write a build out as a static site, for any static host (`tcm build --static <dir>`). A component app's pages are rendered as it's built (prerender): each page it links to, from `/`, is a file (pageFile) with its first paint, server components included, and what they rendered is kept in `_app/trees/`, for the app to read when it goes to another page, or before. Each tree's file (Flight's text) is named by its content (`t.<sha256>.txt`), and so is the map of them the pages name (`_app/site.<sha256>.json`: the file each tree is in, and the trees each page shows), so a browser keeps them for good: only the pages are asked for again. Also: `404.html`, the page that renders any other path in the browser (GitHub Pages, Cloudflare Pages and others serve it for a path with no file), the assets in `_app/assets/`, a PWA's service worker (`sw.js`), which keeps every page, and `.nojekyll` (so GitHub Pages serves `_app`). It's for the path the site is served under (`base`). An app that calls server functions can't be one: there's no server to answer. Files already in `dir` stay, so building into the last build's directory keeps the assets a tab still running it may load.
Serve plain HTTP endpoints, for webhooks and API clients outside the app. A handler takes a standard `Request` and returns a `Response`, plain data (sent as JSON) or nothing (204). The name is resolved on every request, so moving a name moves its URL. There are no CSRF checks here: these are meant to be called from elsewhere.
What the browser runtime's stubs use while a page renders on the server (`globalThis.__tcmSsr`), and the page's `location`, so browser code reading the URL renders the same on both sides. Both follow the request being rendered; outside one, `location` is undefined, as it always is in Node.
Move a build's assets (`<out>/assets`) into the shared directory, compressed: the ones there already stay (the same name is the same content). Their names.
A lease on builds, kept in `work` (buildWorkDir) as a file of this process's own (`lease.<pid>-<random>.json`, written whole), which heldBuilds reads. It's gone once released, or once the process has ended.
`tcm data migrate <table>`: bring every stored row of a table up to its current row type now, through the table's current code (its `migrate` steps), instead of as rows are read. `target` is a table name ("users") or the name of its definition ("crm.users").
A name for what's this process's own among other processes' (`<pid>-<random>`): a build's private directory, a lease, a dev server's files. ownerGone reads the process back from it.
Vite plugins for browser tests: like an app's (server code stubbed, called by hash), with the endpoints answered by the test server itself. `get` sees definitions not stored yet.
Render a component app's pages, as `tcm start` renders a page's first paint, for a static site: from `/`, every page of the app it links to (linkedPaths), each its HTML and the trees its server components rendered (by treeName, Flight's text), which the app reads when it goes to another page, and which trees each page uses. `page` is the page the build has, under the site's `base`.
A page's shell (`url`): what renders the same for every request, rendered once, as partial prerendering does. Its server components that render the same for the same props (`isCacheable`) render in it; the rest, live (they read tables, cookies, the clock), are holes: they suspend, so their nearest `<Suspense>` boundary is left for each request to render (`renderPage`, given the shell). Undefined when the shell itself waits on a live one (one outside any boundary): the page is rendered whole, each time.
Delete old builds: per app, keep the build its name points to now plus the newest `keep` others. Tabs still on a deleted build reload themselves onto the current one at their next server call. What's leased (leaseBuilds) stays: a build being made, and its assets, and the build a `tcm start` serves. What goes is moved aside first, and what was taken hold of meanwhile is put back.
Put a build made in a directory of its own (`staged`, on the same filesystem) in its place, `<apps>/<hash>/`, at once: a rename. A build already there stays, unless `replace` says otherwise of it (another tcm's, or `--force`), and `staged` is dropped: a build is content-addressed, so it's the one this would be. One replaced is moved aside first (to `aside`, then removed), so a reader finds the old build or the new one, each whole. The manifest of the build in place.
A PWA's manifest and images, as its `pwa` (a hash, materialized) says them (webManifest): kept among the assets every build shares, compressed, by their content. Returns their names, with what the page's head gets. `hold` is told each name before it's kept (a build leases them: leaseBuilds).
React Compiler for `compileReact`, installed the first time it's needed. It's asked for before a bundler starts (`tcmPlugin`'s `config`), and before Vitest does (`vitestChild`): installing changes the cache's packages, which a dev server already running would see as new dependencies, and load the page again.
Read a file of a build in place: one being replaced (`--force`, another tcm's) is moved aside an instant before the new one is put there (`publishBuild`), so a file missing is looked for again, for a moment, before that's an error.
Serve an asset of the shared directory: immutable (its name is its content), compressed as the browser accepts. A chunk is offered as a dictionary for the next version of it (`Use-As-Dictionary`), and a browser that has the previous version (`Available-Dictionary`) gets the new one as the difference (`dcb`): a deploy that changes a chunk a little costs the browser a little.
`tcm dev`'s answer to Flight asking where a server stack frame's code is (`/__parcel_source_map?filename=…`, as the browser's React DevTools and console show server components' stacks): a source map of the cache's module, by the name of the codebase's definition in it, with its code, so a frame opens as that code. Only the cache's modules of definitions.
The server-rendering entry for a component app: streams its HTML. The shell (everything outside `<Suspense>` boundaries still waiting) goes out first, the rest as it's ready. Server components render through the host (see renderPage).
Serve the app in production: the build its name points to now, plus every earlier build, so open tabs keep working across deploys. When the name moves, the new version is built (if needed) and becomes current.
Background work for an app: a worker for the durable job queue (functions loaded by hash, so a job runs the code that enqueued it), and the recurring jobs (`every(...)` values) found in the app's namespace.
`pageFiles`, for a browser build: the stylesheets its code only links to, by the name the page knows each by (`styles.css`), filled as the build goes, for the page to name the file each is now (`withStylesheetFiles`), as the import map does for chunks.
Call `onChange` when the codebase changes (`tcm update`, `mv`, `pull`, ... in another shell). One command can change names in several steps (an update, then its propagation), so act only once things have settled for a poll.
PWA_SCRIPT"<script>\nif (\"serviceWorker\" in navigator) {\n const base = globalThis.__TCM_BASE__ ?? \"\";\n…
What a PWA's page runs first: it registers the app's service worker (`sw.js`, under the app's base), and says when a new version has taken over (`tcm:update` on `window`, and `useAppUpdate` in the react library), for the next load. An installed app can stay open for days, so it looks for one whenever it's back on screen (once a minute at most).
The chunk a module of an app's browser code goes in, so what changes together ships together and what doesn't keeps its URL: React (its packages change together, and rarely); the other npm packages; tcm's runtime; and the app's own code; the entry stays its own. A few files, not one per definition: each is a request, and small files compress worse.
Whether an error is a deliberate one, meant for the caller: an `HttpError` (any copy of the server library's), which marks itself with `Symbol.for("tcm.httpError")`. Its status and message reach the browser.
A request for a page, as opposed to an asset, a module or an API call: a browser's GET for HTML, not tcm's own routes or Vite's (`/@vite/`, `/@id/`, `/@fs/`), nor a file by a type tcm serves (`.js`, `.png`). A page's path can hold `@` and dots (`/@alice.dev/geo/1.2.0`).
Cookies a page's server components set after its headers went out (in a boundary that streamed later): the page tells the browser a one-time token, and the browser collects them with it (`POST /__tcm/cookies/<token>`).
Code split for real: what only an `import()` reaches (a `lazy` component's code) stays out of the chunk groups (`chunkGroup`), so it loads when it's needed, in chunks of its own; `chunks` has them, by the module (its component's hash) that imports them, as paths under `/_app/`. A server component's tree naming that `lazy` one has server rendering start loading them with the page (`useFlight`).
The paths of the app a rendered page links to, as it follows them: an `<a href>` under the app's base, with no `download`, `target` or `rel="external"` (as `useAppLinks` leaves to the browser), to a page (no extension but `.html`). Their query and fragment are the page's to read, so they're not part of the path.
The stylesheets of the codebase (`.css` files) the browser's code only links to: every place it uses one is a component whose package gives it the `stylesheet` role (`roles`, by hash: rolesIn; the react library's `<Stylesheet css={…} />`), given the file itself. The browser is sent those as files alone, without their text in its code (stylesheetStandIn); one it uses otherwise (its `length`, put in a string, passed on) keeps its text. Read from the code: every module the browser is sent, each member of it.
The file a static site keeps the page for a path of the app in: `/` is `index.html`, `/today` is `today.html` (static hosts serve it for `/today`), `/docs/` is `docs/index.html`, and `/apps.html` is itself.
An app's page as served under `base`: its assets' URLs under it, and the base said to the page (`__TCM_BASE__`), so the runtime calls the server there and the react library reads and writes paths within it. The build itself doesn't know where it's served: one build serves any base.
An image of a web app manifest (an icon, a screenshot), as the `pwa` says it: its `src` a file of the codebase (an .svg's text, or a .png's, .jpg's, .webp's, .gif's or .ico's bytes), which the build keeps as an asset; the file's type, and a .png's size, read from it. A URL instead is left as it is.
Render server component `fn` with `props` as Flight's text, passing it to `write` as it's ready. An error, in the tree or inside a `<Suspense>` boundary of it, is sent where it happened: what the browser is told of it is `describe`'s, as the error's `digest` (production hides the rest). Whether anything failed.
A page of a component app (`at`, a path within its base), rendered as `tcm start` renders a page's first paint, as a string: for a request with these headers (its cookies, its host). Undefined if it can't render on the server.
The service worker of a PWA's build (`sw.js`, beside its page): it keeps the build (`files`, relative to it: its pages, a static site's trees, and its assets) in a cache of its own when it installs, and takes over at once. A build that calls no server (`offlineFirst`) opens a page it keeps from that cache, online or not, so it starts at once; one that does asks the network for its page first. A path it keeps no page for is the network's, and, with no network, `shell`'s (the page that renders any path in the browser). Assets come from the cache (their names are their content). A new build's service worker replaces it when the page is next opened or comes back on screen; the build before it is kept, for a tab still running it.
The file a stylesheet of the codebase (a `.css` file) is served as, under `/_app/assets/`: its name and its hash, so it's kept for good, and the same in every build that has it. Named as a chunk is (`chunkStem`), so a browser holding the last version of it is sent the next as what changed.
What a stylesheet's module says as it loads in an app's build: the file it's served as, by its content (or the stand-in it has instead), for the react library's `<Stylesheet>` (the `stylesheet` role) to link to. `fromPage`: the file is the one the page names for `asset` (`__TCM_STYLESHEET_FILES__`, which the build writes into it), so the module doesn't change when the stylesheet does.
What the browser's code is given for a stylesheet it only links to, rather than its text: a comment naming the file it's served as, which `<Stylesheet>` links to as it would the text (and which, written into a page, is still CSS).
An app's web app manifest, from its namespace's `pwa`: the manifest as the spec has it, written as an object, with its images as files of the codebase. `keep` stores a file the manifest needs among the build's assets and names it (`icon-<digest>.png`); the manifest is one of them too, and its URLs (`start_url`, `scope`, shortcuts' `url`) are the app's paths (`/` is the app), whatever path it's served under. Defaults: the app's root as `start_url` and `scope`, and `display: "standalone"`. Returns the tags the page's `<head>` gets (its viewport, manifest, theme color and icons), its title, and what an installed app would miss.
A page with an import map: chunks import each other by names that don't change with their content, and the map, in the page (which is never cached), says which file each is now. So a chunk that changed doesn't change the chunks that import it. Before any module script, as browsers require.
A page naming the file each stylesheet its code only links to is now (`__TCM_STYLESHEET_FILES__`, by the name the code knows it by), as the import map names chunks: the page is never cached, so a stylesheet that changed doesn't change the code linking to it. Before any module script, which reads it as it loads.
A stylesheet the browser's code only gives a component with the `stylesheet` role (`<Stylesheet css={…}>`) is linked to alone; one it reads as text too (or gives `<Stylesheet>` through a name of its own, or gives another component) keeps its text.