This document details the sharing mechanism in the Next.js Module Federation plugin, showing how it handles sharing between client and server environments across Next.js versions 14 and 15.
flowchart TB
Next.js implements a sophisticated server-side HMR system that coordinates multiple webpack compilers, handles server component updates, and manages complex caching mechanisms. This document provides a comprehensive analysis of the server-side HMR architecture.
graph TB
The ExportInfoDependency
is a critical component in rspack's export tracking system that provides runtime access to export metadata during code generation. It acts as a bridge between the analysis phase (where export usage information is collected) and the runtime phase (where this information is used for optimizations).
TL;DR: We tested Advanced Dictionary Compression (ADC) technology on real-world JavaScript files (4MB each). The results demonstrate significant improvements:
This document provides a comprehensive specification for the Hot Module Replacement (HMR) runtime, specifically tailored for a Node.js environment where update chunks are loaded from the filesystem and executed within the current V8 context using the vm
module. This runtime enables developers to update modules in a running Node.js application without a full server restart, significantly speeding up development workflows.
The primary purpose of this HMR runtime is to:
// Utility functions that would only be used by newFeature | |
function formatMessage(message) { | |
return `[NEW] ${message}`; | |
} | |
function validateFeature() { | |
return true; | |
} | |
function logFeatureUsage(featureName) { |
{ | |
"tools": [ | |
{ | |
"type": "function", | |
"function": { | |
"name": "codebase_search", | |
"description": "Find snippets of code from the codebase most relevant to the search query.\nThis is a semantic search tool, so the query should ask for something semantically matching what is needed.\nIf it makes sense to only search in particular directories, please specify them in the target_directories field.\nUnless there is a clear reason to use your own search query, please just reuse the user's exact query with their wording.\nTheir exact wording/phrasing can often be helpful for the semantic search query. Keeping the same exact question format can also be helpful.", | |
"parameters": { | |
"type": "object", | |
"properties": { |
const HtmlWebpackPlugin = require('html-webpack-plugin'); | |
const {ModuleFederationPlugin} = require('webpack').container; | |
const {RuntimeGlobals, RuntimeModule} = require('webpack'); | |
const path = require('path'); | |
const deps = require('./package.json').dependencies; | |
class Testing123RuntimeModule extends RuntimeModule { | |
constructor() { | |
super('testing123', RuntimeModule.STAGE_BASIC + 1); | |
} |
/******/ // load script equivalent for server side | |
/******/ __webpack_require__.l = function(url,callback,chunkId) { | |
/******/ if(!global.__remote_scope__) { | |
/******/ // create a global scope for container, similar to how remotes are set on window in the browser | |
/******/ global.__remote_scope__ = { | |
/******/ _config: {}, | |
/******/ } | |
/******/ } | |
/******/ | |
/******/ function executeLoad(url, callback, name) { |
import { injectScript } from '@module-federation/utilities'; | |
// example of dynamic remote import on server and client | |
const isServer = typeof window === 'undefined'; | |
//could also use | |
// getModule({ | |
// remoteContainer: { | |
// global: 'app2', | |
// url: 'http://localhost:3002/remoteEntry.js', | |
// }, | |
// modulePath: './sample' |