microfrontends

Summary detect overlaps between parameterized path expressions by testing synthesized concrete paths preserve existing duplicate and concrete-path conflict reporting behavior bound synthesized candidates to keep validation work predictable add regression coverage for wildcard-vs-wildcard conflicts Testing pnpm checks -F @vercel/microfrontends focused validation suite: 113 tests passed full package suite: 32 suites and 385 tests passed git diff --check Scope This fixes the proven parameterized-path intersection gap in validateConfigPaths. It does not claim to explain or prevent the unrelated cached OSS badge 404 incident. Full repository checks The full pnpm checks command was attempted. Unrelated example tasks failed because Turbopack could not bind helper ports in the sandbox, the App Router example requires its custom microfrontends config filename environment variable, Google Fonts was unavailable, and a Playwright Chromium install stalled under restricted network access.

This PR changes the proxy URL line printed at startup to show the configured origin, if set by or an env var, while also showing the loopback port binding for reference. Currently, the origin is printed on a second line:

Summary The command runs a local development proxy that sits in front of your locally running microfrontends, routing each request to the right app (or to a production fallback when an app isn't running locally). Until now it assumed browsers always reach it at . Every request it forwarded to an app looked like it came from that localhost address, and any redirect coming back from a production fallback was rewritten to point at localhost. That assumption breaks the moment the proxy is reached through anything other than raw localhost. Developers increasingly front it with a custom hostname or a TLS terminator (for example ) so local development matches production more closely. In that setup the app behind the proxy has no way to learn the URL the browser actually used, which breaks absolute URL generation, canonical links, and auth redirect flows. This PR adds an optional configured origin. Set it with or the environment variable. When configured, the proxy tells downstream apps about that origin via the standard / / headers, and rewrites fallback redirects onto it. When it is not configured, behavior is identical to before. What changed A new flag on the proxy command flows into , , and the constructor, alongside a read of the environment variable. The resolved value is validated once at construction and stored as . On both request paths (the local app path and the production-fallback path), the proxy now attaches derived from the configured origin, so the app sees the browser-facing scheme, host, and port instead of the internal localhost target. Fallback redirects (301/302/307/308 from a production app) are rewritten onto the proxy's browser-facing origin so the browser stays on the local host rather than being bounced to production. Upgrade requests receive the same forwarded headers as regular requests when an origin is configured, so dev-time WebSocket traffic (such as HMR) is consistent with HTTP traffic. accepts only a bare absolute origin. Anything with a path, query string, hash, or credentials is rejected with a clear error. The README and the microfrontends skill reference document the flag and env var, and a minor changeset is included for . Design decisions and rationale I try to justify each major design decision below. 1. A single explicit , rather than an list that trusts inbound . Why not just trust the forwarded headers a fronting proxy already sends? Because the proxy also has to rewrite production redirects onto one canonical origin, and per-request inbound headers give no answer when a request arrives without them. Why would they be absent? Redirects come back on the custom fallback path, and many local TLS setups (mkcert, socat, an SSH tunnel, plain resolution) set no forwarded headers at all. So what would an allowlist need? A default origin anyway, for every no-header case. Then why do origin allowlists exist elsewhere? To defend against forged forwarded headers from untrusted clients, which is a production-edge concern, not a dev server concern. Does that threat apply here? No. This is a process on the developer's own machine. The allowlist would guard a threat that doesn't exist while making the redirect case explained above more confusing. → _A single declared origin is deterministic, works regardless of what fronts the proxy, and is the more defensive choice (it never trusts a spoofable inbound host)._ 2. Header injection is additive: forwarded headers are attached only when an origin is configured. Why gate it? Existing users set no origin. Always injecting (defaulting to localhost) would override inbound values those setups may already rely on. Why is overriding worse than leaving them? When no origin is configured, the proxy does not actually know the browser-facing origin, so replacing inbound headers with a guessed localhost is, I will argue, strictly worse. When is ignoring inbound headers legitimate then? Only once the user has told us the real origin, which is the configured case. → _The feature must be purely additive, so behavior with no origin configured matches today's exactly and no existing setup regresses._ 3. Strict origin validation.** Why reject a value with a path or credentials? The origin is used to build forwarded headers and redirect targets, so a stray path, query, or userinfo would produce malformed headers or leak credentials downstream. Why fail rather than sanitize? Silently trimming a malformed value hides a configuration mistake and produces surprising URLs. → _The only meaningful shape for this input is a bare origin, so it is validated as exactly that and rejected loudly otherwise._ Testing and impact Unit tests cover origin resolution from both the flag and the environment variable, the flag taking precedence over the environment variable, rejection of invalid origins, forwarded-header injection on requests and WebSocket upgrades, pass-through of inbound headers when no origin is configured, and redirect rewriting onto the configured origin. Because the entire feature is gated on an explicitly configured origin, projects that do not set one are unaffected.