Skip to content

Issues/50 - Basic support for SSR#51

Merged
Aukevanoost merged 5 commits into
mainfrom
issues/50
May 31, 2026
Merged

Issues/50 - Basic support for SSR#51
Aukevanoost merged 5 commits into
mainfrom
issues/50

Conversation

@Aukevanoost
Copy link
Copy Markdown
Contributor

This pull request introduces significant improvements to the developer experience and reliability of server-side rendering (SSR) for federated Angular projects using native federation. The main focus is on ensuring correct initialization order for module federation in SSR, robust handling of host singletons, and improved schematic setup for new projects. The changes address issues that could cause multiple Angular instances (leading to errors like NG0203) and streamline both development and production SSR workflows.

SSR Federation Initialization and Build Process:

  • Replaces the previous SSR bootstrap mechanism with a new system that emits an Angular-free server.mjs entry point, ensuring the federation node loader is registered before any Angular code is evaluated. The original Angular entry is renamed to bootstrap-server.mjs, and a new, orchestrator-focused entry is written as server.mjs (writeFederationServerEntry, federationServerEntry). [1] [2]
  • For local development (ng serve), injects a dev-only host-instances bootstrap into the SSR bundle using a new esbuild plugin, ensuring singleton sharing between host and remotes, and preventing multiple Angular core instances. This includes the new devHostInstancesPlugin and code generation via generateDevHostInstancesEntry. [1] [2] [3] [4]

Schematic Improvements for SSR Projects:

  • Updates the schematic's SSR setup to only modify the existing server.ts to enable CORS and ensure the server listens correctly when imported, rather than attempting to initialize federation there (which is now handled by the generated entry).
  • Adds a new schematic step to switch the default scaffolded route render mode from Prerender to Server, since federated remotes cannot be prerendered. [1] [2] [3]
  • Ensures the orchestrator package is added as a runtime dependency for SSR projects (not just dev), and removes the now-unnecessary @softarc/native-federation-node dependency. [1] [2]

Configuration and Security:

  • Automatically configures allowedHosts to include localhost in the esbuild options for SSR projects, ensuring SSR works out of the box in local development by preventing silent fallback to client-side rendering due to host header rejection.

These changes collectively make SSR with module federation in Angular more robust, developer-friendly, and production-ready.

Most important changes:

SSR Federation Initialization and Build Process

  • Replaced the previous SSR bootstrap with a new system that emits an Angular-free server.mjs entry, ensuring the federation node loader is registered before any Angular code is evaluated. The original Angular entry is renamed to bootstrap-server.mjs, and a new orchestrator-focused entry is written as server.mjs (writeFederationServerEntry, federationServerEntry). [1] [2]
  • Injected a dev-only host-instances bootstrap into the SSR server bundle for local development using a new esbuild plugin (devHostInstancesPlugin) and dynamic code generation (generateDevHostInstancesEntry), ensuring singleton sharing and preventing multiple Angular core instances. [1] [2] [3] [4]

Schematic and Dependency Improvements

  • Updated the schematic's SSR setup to only modify server.ts for CORS and correct listening, leaving federation initialization to the new generated entry.
  • Added a schematic step to switch the default render mode from Prerender to Server in app.routes.server.ts for SSR projects, since remotes cannot be prerendered. [1] [2] [3]
  • Changed orchestrator dependency to be a runtime dependency for SSR projects and removed the now-unnecessary @softarc/native-federation-node dependency. [1] [2]

Configuration and Security

  • Ensured allowedHosts includes localhost in SSR esbuild options to prevent silent fallback to client-side rendering during local development.

@Aukevanoost Aukevanoost merged commit 1c242c4 into main May 31, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant