For AI agents: the complete documentation index is available at https://mfdoctor.kevinbeier.com/llms.txt, the full documentation bundle is available at https://mfdoctor.kevinbeier.com/llms-full.txt, and this page is available as Markdown at https://mfdoctor.kevinbeier.com/production-readiness.md.
MFDoctor
  • English
  • 1.1.0

      • Production readiness

      MFDoctor treats Module Federation as three linked surfaces:

      1. build configuration,
      2. emitted manifest/stats/type artifacts,
      3. federation-wide runtime contracts.

      A config can be valid by itself and still fail after deployment. For example, an externalRuntime remote is only safe when a pure top-level consumer provides the runtime first. MFDoctor therefore keeps local and cross-project checks separate.

      Coverage map

      SurfaceExamplesMain benefit
      Identity and formatname, filename, library, remoteTypeCorrectness
      Remote loadingremotes, HTTPS, manifest entries, shareStrategyReliability and startup speed
      Sharingscopes, versions, singleton, eager, fallback, tree shakingCorrectness and bundle size
      Runtimeplugins, async startup, external runtime, snapshot capabilitiesReliability and performance
      Outputmanifest, stats, remote entry, type metadata, asset mapsDeploy safety
      Vite-onlyparse timeouts, CSS bundling, runtime feature removalBuild and runtime performance

      The rule reference groups every diagnostic by correctness, reliability, performance, security, or tooling. Each rule page includes the impact, a concrete fix, and upstream evidence.

      Important distinctions

      Core/Rspack/Rsbuild options come from the Module Federation plugin types. They include runtime plugins, manifest, DTS, async startup, external runtime, snapshot optimization, and shared tree shaking.

      Vite has its own integration and extra options. Its normalized option type adds publicPath, bundleAllCSS, parser timeouts, injection location, SSR externals, and direct runtime capability flags. A MFDoctor rule says when it is Vite-only; it does not pretend the setting exists in every bundler.

      Production policy

      Recommended CI policy — register the plugin and let CI env auto-detect do the rest (failOn: "error" + SARIF when CI / provider vars are set):

      import { federationDoctor } from "@tonoizer/mfdoctor/vite";

federationDoctor({
  moduleFederation: mfOptions,
});

      Force CI or local defaults only when needed: mode: "ci", mode: "development", or an explicit failOn. Use mfdoctor check --ci when running the CLI outside a CI provider.

      Use mfdoctor federation ".mf/doctor/**/project.json" after every application has produced project.json. This is where name collisions, version/scope conflicts, missing providers, and external-runtime provider gaps become visible. Together with plugin emit, that is the green bar — not mfdoctor check alone (see the agent loop).

      For incremental adoption, check in a fingerprint baseline so known debt stays visible in reports without failing the gate. Baselines are debt — prune them as findings are fixed.

      MFDoctor stays offline by default. It records normalized config and artifact metadata, not source bodies, secrets, or live remote responses.

      Install MFDoctor as a devDependency. Adapters analyze after emit in Node; they are not part of the client bundle. MF runtimePlugins are covered through the shared bundler mfOptions object — not by shipping MFDoctor into the runtime.

      Research sources

      Use primary upstream references when changing rules or claiming Module Federation behavior. The repository contribution guide keeps the maintainer source list. High-level entry points:

      The official agent-skill repository currently has no license file. MFDoctor does not vendor its code or browser asset. MFDoctor-specific agent UX prefers CLI and plugin finding output; .agents/skills/mf remains for Module Federation concepts.