Build Output Anatomy

A production build is not a compiler handing back "the app" as one file. It leaves a directory of artefacts with different producers, different consumers and different lifetimes. Most meta-frameworks emit the same four kinds, whatever their authoring model, and being able to name them is what lets you answer "what does this deployment actually need?" without guessing. ## The four kinds **Content-hashed client assets.** The JavaScript the browser executes, the CSS it applies, and files copied verbatim from the project's public folder. Generated ones are named with a hash of their own contents, so a logical `app.js` is emitted as something like `app.9f2c1a4b.js`. The consequence that matters here is that the *name identifies the bytes*: nothing is ever overwritten, and a file whose contents did not change keeps its name from build to build. How long each category may be cached is a caching-policy question in its own right. **Prerendered documents.** For every route whose HTML could be determined at build time, the build writes a finished document to disk, usually at a path mirroring the URL. These are ordinary HTML files: no server is needed to produce them, only to hand them over. They normally embed the serialised data the page was rendered with, so the client can take over the existing markup without re-fetching what the build already had. **A server bundle.** Everything not resolved at build time is compiled into a bundle with a request-handling entry point: per-request routes, data and form endpoints, middleware, and the rendering runtime. Its packaging depends on what the build was told to target - a long-running process, a per-request function, an edge runtime - but its role is constant. It is the code that must execute after deployment. **Manifests.** Machine-readable indexes that glue the other three together: which URL pattern maps to which prerendered document or server handler, and which asset files a route needs. Because assets carry content hashes, nothing can hard-code their names; the manifest is how generated HTML and the client runtime discover them. ## How they differ | Artefact | Produced | Consumed by | Needs code at request time | |---|---|---|---| | Hashed client assets | Once, at build | The browser | No | | Prerendered documents | Once, at build | The browser, served as-is | No | | Server bundle | Once, then executed per request | The hosting target | Yes | | Manifests | Once, at build | The server bundle and client router | No, but read by code that does | The line that matters runs through the middle of that table. The first two rows are **results**; the third is a **program**. An output with no server entry point describes an application that is finished. An output with one describes an application that is only half finished until something runs it. ## Reading an output directory 1. Find the directory of hash-named files. That is the client graph - what browsers download. 2. Find the `.html` files laid out like the site's URLs. Those routes already exist as documents. 3. Find a bundle with a server or handler entry point. If there is one, part of the app still has to run somewhere. 4. Open the route manifest. It is the authoritative statement of which URLs are answered from disk and which are answered by code - more reliable than inferring it from the file tree. ## A common misreading The most frequent mistake is to call the whole output "static" because it is all sitting on disk. Files on disk and a static deployment are not the same claim: the server bundle is a file on disk too, and so is an on-demand transformer that reshapes assets when they are requested. "Static" is a statement about whether anything must execute to answer a request, and the honest way to settle it is to find the entry points, not to look at file extensions. ## What the output does not tell you Meta-frameworks differ in how visible they make all this: some publish the output layout as a documented contract you may read and build on, while others treat it as internal and expect you to go through a translation layer for whichever hosting shape you chose. The artefact *categories* are stable across them, which is why the vocabulary transfers even when the directory names do not. Two things a directory listing genuinely will not tell you. First, freshness policy: whether a prerendered document is meant to survive until the next build or to be replaced while the app runs is a property of how the route was configured, not of the file. Second, cost: a server bundle's existence says code must run, not how much of it runs per request or how heavy that is.