How do a build's base path and asset origin appear in its output, and what breaks when either is wrong?
answer
- the build cannot see its own address
- written into URLs, not discovered
- the runtime composes later URLs too
- a separate origin means cross-origin rules
basics
~20 sBoth are baked in at build time, prefixing asset URLs in generated HTML, in manifests, in emitted CSS and in the client runtime that composes chunk URLs later. Get either wrong and documents render while their assets fail to load.
solid answer
~50 sThe output is produced before it is served, so it cannot discover where it will be mounted: if the app lives under a sub-path, the build has to be told, and that value is written into every URL it emits. An **asset origin** does the same for a different reason - it points asset URLs at a separate host while documents stay on the app's own origin. Two things follow. First, the client runtime keeps that base and composes URLs for chunks it fetches *after* load, so a proxy that rewrites only the served HTML fixes the first page and nothing after it. Second, a separate origin makes asset requests cross-origin, so fonts and module scripts need the right allow headers from that origin, and script errors reported to the page arrive without detail unless the requests are made with cross-origin attributes.
go deeper
Know that the folder or host an app is served from is something the build is told in advance, and that getting it wrong shows up as assets failing to load rather than as a build error.
Explain that the value is written into documents, manifests, CSS references and the client runtime's base, and why that makes rewriting the HTML alone an incomplete fix.
Read the signature and name the cause: unstyled first page, or a first page that works until you navigate. Add the cross-origin consequences - allow headers for fonts and module scripts, and opaque script errors.
Decide whether one artefact must serve several mount points. If it must, the base stops being a build-time constant and becomes something the document carries, which is a design commitment rather than a configuration tweak.
A build emits URLs. It has to, because the documents and stylesheets it produces reference files by address. But a build runs before anyone serves the output, so it cannot observe the address it will be reached at. Two settings close that gap: the **base path** (the prefix the app is mounted under, when it is not the site root) and the **asset origin** (the host that serves the app's static files, when it is not the host that serves the documents). ## Why the build has to be told A document served at a sub-path still has to reference a stylesheet by URL. If the build assumed the site root, that URL points outside the mount and resolves to nothing. Relative URLs help in the simple cases but not in general: a route nested several segments deep resolves relative references differently from a shallow one, and any URL the application composes at runtime has no document to be relative to. So the base becomes a build-time constant, and every place the build writes a URL gets it. ## Where the value lands in the output - Script, stylesheet, image and preload references inside **generated and prerendered documents**. - **Asset URLs recorded in manifests**, which everything else resolves through. - URL references **inside emitted CSS**, which resolve relative to the stylesheet's own location rather than the document's. - The **client runtime's base**, used to compose chunk URLs for routes visited after the first page. - Internal link and redirect targets that were resolved during prerendering. That spread is the whole reason a half-fix is so common. Patching the HTML is easy and visible; the other four are not, so the deployment appears to work until someone navigates. ## Base path and asset origin compared | | Base path | Asset origin | |---|---|---| | What it changes | The prefix documents and assets are addressed under | The host assets are fetched from | | Applies to documents | Yes | No - documents stay on the app's origin | | Typical reason | The app is mounted under a sub-path | Assets are served from a CDN or dedicated host | | Extra consequence | Internal links and redirects must agree | Requests become cross-origin | ## Failure signatures - **A page that renders as unstyled, inert markup.** The document was found by its own URL, so it is served correctly; everything it points at is 404. This reads to a user as "broken layout" rather than "not found", which is why it is often misdiagnosed as a rendering fault. - **The first page works and navigation fails.** The classic signature of a proxy that rewrites the served HTML but cannot touch the base the client runtime holds. Later chunk requests are composed from the un-rewritten value. - **Styles load but the images and fonts they reference do not.** The CSS was rewritten or copied without its URL references being adjusted, and those resolve against the stylesheet's location. - **Cross-origin asset failures.** Fonts and module scripts are fetched under cross-origin rules, so the asset origin must return the appropriate access-control response headers or the browser rejects a response it downloaded successfully. - **Error reports with no detail.** An uncaught error in a script fetched from another origin is reported to the page opaquely unless that script was requested with cross-origin credentials-mode attributes and the origin permits it, so a production error monitor shows a message with no stack. ## What this means in practice The base path is a property of *this build*, not of the machine serving it. If the same artefact has to be reachable under two different prefixes, the base can no longer be a constant: the document must carry it and the runtime must compose every URL from that value, including the ones it builds after load. Otherwise the prefix is frozen into the output and the honest answer is that the second deployment needs its own build. Meta-frameworks differ in how much they let you defer here - some resolve the base entirely at build time, others read a value injected into the document - so check which model you are on before promising a single artefact will serve both.
- Why can a wrong base path leave a page looking almost right rather than failing outright?Because the document itself was found by its own URL and served normally. What breaks is everything it points at - stylesheet, client bundle, images - so you get readable markup with no styling and no interactivity. It reads as slow or half-loaded until someone opens the network log.
- Besides script and stylesheet tags, where else does the base path appear in the output?In manifest asset URLs, in URL references inside emitted CSS, in preload hints, in internal links and redirect targets resolved during prerendering, and in the client runtime's base for chunks fetched after load. That spread is why patching only the HTML leaves a half-working deployment.
saying these in an interview costs you the question
- Thinks a proxy prefix can be added after the build without rebuilding
- Believes relative URLs solve sub-path deploys for deeply nested routes too
- Forgets that a separate asset origin needs access-control response headers
- Expects a wrong base path to fail the build rather than at request time
- Thinks only the initial document references assets, not code running later