Implementing Hot Module Replacement (HMR) in JavaScript

Hot Module Replacement (HMR) is a powerful feature in modern JavaScript development that allows modules to be updated live in the browser without a full page refresh. This significantly speeds up development workflows by preserving application state while applying changes. This challenge asks you to implement a basic HMR system that can replace modules dynamically.

Problem Description

You are tasked with creating a simple HMR system for a JavaScript application. The system should be able to:

1. Detect Module Changes: Monitor a specified directory for changes to JavaScript files.
2. Replace Modules: When a change is detected, replace the corresponding module in the browser with the updated version.
3. Preserve State: Crucially, HMR should attempt to preserve the application's state. This means that when a module is replaced, any existing instances of that module should be updated rather than recreated.
4. Basic Acceptance Function: Provide a mechanism for modules to define an "accept" function. This function will be called when the module is replaced, allowing it to react to the update (e.g., re-render components, re-establish event listeners).

Key Requirements:

• The solution should use Node.js's fs module to watch for file changes.
• The solution should use webpack's HotModuleReplacement.apply method to apply the HMR update. You'll need to mock a module and module.hot object for testing purposes.
• The solution should handle basic module dependencies. If a module depends on another module, the dependent module should also be updated when the dependency changes.
• The solution should provide a way to specify the directory to watch.

Expected Behavior:

• When a JavaScript file in the watched directory is modified, the HMR system should detect the change.
• The corresponding module in the browser should be replaced with the updated version.
• The module's "accept" function (if defined) should be called.
• The application's state should be preserved as much as possible.
• The system should not crash or throw errors when a module is replaced.

Edge Cases to Consider:

• What happens if a module is deleted?
• What happens if a module is renamed?
• How should circular dependencies be handled? (For simplicity, you can assume there are no circular dependencies in this challenge.)
• How to handle errors during module replacement?

Examples

Example 1:

Input:
Watched Directory: './modules'
Module: './modules/moduleA.js'
Content of moduleA.js (initial): `export const message = 'Hello';`
Content of moduleA.js (updated): `export const message = 'Hello World!';`

Output:
The 'accept' function of moduleA.js (if defined) is called.
The value of 'message' in any other module importing moduleA.js is updated to 'Hello World!'.

Example 2:

Input:
Watched Directory: './modules'
Module: './modules/moduleB.js'
Content of moduleB.js: `import { message } from './moduleA.js'; console.log(message);`
moduleB.js is updated to: `import { message } from './moduleA.js'; console.log(message);` (no change)

Output:
No action is taken. The 'accept' function of moduleB.js is not called.

Example 3: (Edge Case - Module Deletion)

Input:
Watched Directory: './modules'
Module: './modules/moduleC.js'
moduleC.js is deleted.

Output:
The module is removed from the application.  Any modules importing moduleC.js should handle the missing dependency gracefully (this is not required to be implemented in this challenge, but should be considered).

Constraints

• The solution must be implemented in JavaScript using Node.js.
• The solution must use the fs module for file system monitoring.
• The solution must use webpack's HotModuleReplacement.apply method.
• The watched directory must be configurable.
• The solution should be able to handle a reasonable number of modules (e.g., up to 100).
• Performance should be considered; avoid unnecessary file reads or module replacements.

Notes

• You don't need to implement a full-fledged webpack server. Focus on the core HMR logic.
• You can mock the module and module.hot objects for testing purposes. A simple mock is sufficient.
• Consider using a debounce function to avoid triggering HMR too frequently when a file is being edited.
• The "accept" function is a crucial part of HMR. Make sure it's called correctly when a module is replaced.
• Error handling is important. Gracefully handle errors that may occur during module replacement.
• Think about how to identify modules and their dependencies. Simple string matching of import statements is a reasonable approach for this challenge.