Orientation
Content Processing
Search Infrastructure
Rendering and UI
Developer Tooling
How It Works
The following files were used as context for generating this wiki page:
The createMDX process acts as the integration layer between Fumadocs and Next.js. At a high level, this flow initializes the MDX core, manages configuration loading, and prepares the necessary paths so that loaders can resolve the compiled MDX configuration during the build or development process.
This process is critical for ensuring that MDX files are transformed using the correct project-specific configuration. By dynamically determining the location of the compiled configuration file, the system maintains a seamless link between user-defined source.config.ts files and the underlying build tools.
createMDXThe entry point createMDX is invoked by the user's next.config.mjs. It orchestrates the setup of the Core instance and checks if the environment needs initialization. If _FUMADOCS_MDX is not set, it triggers the init function to start the development environment or initial compilation.
Sources: packages/mdx/src/next/index.ts:30-38
initThe init function prepares the environment. It defines internal utilities for managing config lifecycle (initial load and reload) and handles the development server instance if the environment is in development mode.
Sources: packages/mdx/src/next/index.ts:124-182
devServerWhen in development, devServer initializes a file watcher (via chokidar) to monitor changes to the configuration file or content collections. It ensures that whenever a user modifies the configuration, the system triggers a reload of the core logic.
Sources: packages/mdx/src/next/index.ts:132-176
initOrReloadThis function is called both during startup and on file changes. It executes core.init and passes in the loaded configuration, which effectively re-hydrates the application with the latest user settings.
Sources: packages/mdx/src/next/index.ts:125-130
loadConfigThis utility compiles the source configuration file using esbuild if requested, and then imports the generated module. It ensures the configuration is ready to be consumed by the plugins and core modules.
Sources: packages/mdx/src/config/load-from-file.ts:35-44
getCompiledConfigPathFinally, this method on the Core object computes the expected filesystem location of the source.config.mjs file. This path is then used by the Webpack loaders to access the compiled configuration variables during the compilation of MDX content.
Sources: packages/mdx/src/core.ts:218-220
Note
The getCompiledConfigPath method does not verify file existence; it merely provides the standard path based on the output directory configuration.
Sources: packages/mdx/src/next/index.ts
Sources: packages/mdx/src/next/index.ts
next package integration layer to the config management utilities and finally to the core logic layer.compileConfig, failure to build the configuration file results in an explicit error, preventing further execution with invalid settings.Date.now() as a search param on the import URL (in loadConfig) to bust the node module cache, ensuring that hot-reloaded configurations are always current.devServer uses chokidar to detect configuration changes. It calls watcher.removeAllListeners() before restarting to prevent listener leaks during hot reloads.Tip
If you encounter issues where MDX configuration changes aren't being reflected, ensure that your outDir (default .source) is not being ignored by your IDE or build cache.
Warning
Manual editing of the files inside the .source directory is discouraged as they are generated by esbuild during the loadConfig process.