feat: polyfill lynx.requireModuleAsync to allow cache same parallel requests

[upupming]

This is a polyfill for lynx.requireModuleAsync temporarily to make sure it can cache PARALLEL request. The final resolution is that lynx.requireModuleAsync should support it by default.

It is a very important feature for chunk splitting. Without this, the lynx.requireModuleAsync will execute twice for the same request. For example, when chunk splitting is enabled, we will generate the following output:

"/app-service.js":

lynx.requireModuleAsync(\"http://x.x.x.x:3000/static/js/lib-preact.js\"),lynx.requireModuleAsync(\"http://x.x.x.x:3000/static/js/vendors-_react_background_node_modules_pnpm_lynx-js_preact-devtools_5_0_1_node_modules_lynx-j-5bc771.js\");module.exports=lynx.requireModule(\"/.rspeedy/main/background.js\",globDynamicComponentEntry?globDynamicComponentEntry:'__Card__');});return tt.require('/app-service.js');}return{init:n}})()

"/.rspeedy/main/background.js":

// Lynx startup chunk dependencies
(() => {
var next = __webpack_require__.x;
__webpack_require__.x = () => {
return Promise.all([
	__webpack_require__.e("lib-preact"),
	__webpack_require__.e("vendors-_react_background_node_modules_pnpm_lynx-js_preact-devtools_5_0_1_node_modules_lynx-j-5bc771")
]).then(next);
};
})();

__webpack_require__.f.require = function (chunkId, promises) {
  lynx.requireModuleAsync(__webpack_require__.p
        + __webpack_require__.u(chunkId), (err, exports) => {
        if (err) {
            reject(err);
            return;
        }
        installChunk(exports);
        resolve(exports);
    });
}

In this example, /app-service.js and /.rspeedy/main/background.js will both call lynx.requireModuleAsync(\"http://x.x.x.x:3000/static/js/lib-preact.js\"). Our original goal is to fetch lib-preact.js as soon as app-service.js loads and reuse it in background.js, but as they are parallel and app-service.js does not finish its loading before background.js, lynx.requireModuleAsync fails to use cache now.

Let's see trace before and after this fix:

• before

• after

Summary by CodeRabbit

• New Features
  • Introduced caching mechanism for parallel async module requests. When the same module is requested concurrently from multiple sources, the first load is cached and shared across all concurrent requestors. Subsequent identical requests reuse the cached result, eliminating redundant module evaluations.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

Checklist

• Tests updated (or not required).
• Documentation updated (or not required).
• Changeset added, and when a BREAKING CHANGE occurs, it needs to be clearly marked (or not required).

[changeset-bot]

🦋 Changeset detected

Latest commit: 12a75f2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@lynx-js/template-webpack-plugin	Patch
@lynx-js/react-rsbuild-plugin	Patch
@lynx-js/react-alias-rsbuild-plugin	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coderabbitai]

📝 Walkthrough

Walkthrough

A changeset entry and polyfill implementation for caching consecutive module loads in lynx.requireModuleAsync are introduced. The polyfill is integrated into the app-service script generation, with comprehensive tests verifying caching behavior and syntax validity.

Changes

Cohort / File(s)	Summary
Changeset & Core Polyfill .changeset/silent-actors-marry.md, packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts	New changeset for patch release. New polyfill function exports JavaScript code that wraps lynx.requireModuleAsync to cache module loads by URL, queuing callbacks for in-flight requests and returning cached results on completion.
Plugin Integration packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts	Imports and injects the polyfill into assembled app-service parts when external assets exist.
Unit Tests packages/webpack/template-webpack-plugin/test/basic.test.ts	New test suite for polyfill behavior, verifying that parallel identical requests are cached and evaluated only once, with error handling across multiple scenarios.
Inline Script Tests packages/webpack/template-webpack-plugin/test/cases/inline-scripts/*	Updated test cases across external, inline-fn, inline-object, inline-partial, inline-regex, and inline directories to verify polyfill presence (moduleCache declaration) and evaluate inlined app-service scripts for syntax errors.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• fix: app-service.js contains module.exports=; #1501: Fixes malformed app-service output in the same LynxEncodePlugin, directly relevant to app-service generation modifications.
• fix: missing comma in app-service manifest on chunk split #1279: Modifies app-service manifest assembly logic in LynxEncodePlugin, overlapping with the plugin integration changes.

Suggested labels

platform:Web

Suggested reviewers

• colinaaa

Poem

🐰 A rabbit hops through caching lanes,
Where modules load with shared refrains,
No duplicate work, just one swift call,
The polyfill magic serves them all! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: implementing a polyfill for lynx.requireModuleAsync to enable caching of identical parallel requests, which aligns with the core functionality added across all modified files.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will degrade performance by 5.51%

_{Comparing feat/requireModuleAsyncCache (12a75f2) with main (9de99b0)}

Summary

❌ 1 regressed benchmark
✅ 62 untouched benchmarks
⏩ 3 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
❌	transform 1000 view elements	43.4 ms	46 ms	-5.51%

Footnotes

1. 3 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[relativeci]

Web Explorer

#7173 Bundle Size — 383.59KiB (0%).

12a75f2(current) vs 9de99b0 main#7166(baseline)

Bundle metrics   1 change

	Current #7173	Baseline #7166
Initial JS	154.03KiB	154.03KiB
Initial CSS	35.05KiB	35.05KiB
Cache Invalidation	0%	0%
Chunks	8	8
Assets	8	8
Modules	237(-0.42%)	238
Duplicate Modules	16	16
Duplicate Code	3%	3%
Packages	4	4
Duplicate Packages	0	0

Bundle size by type  no changes

	Current #7173	Baseline #7166
JS	251.56KiB	251.56KiB
Other	96.98KiB	96.98KiB
CSS	35.05KiB	35.05KiB

Bundle analysis report Branch feat/requireModuleAsyncCache Project dashboard

---

^{Generated by RelativeCI Documentation Report issue}

[coderabbitai]

Actionable comments posted: 5

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-partial/index.js (1)

34-37: Nested it() block is invalid test structure.

Same issue as in inline-object/index.js — this inner it() is nested inside the outer it() starting at line 15 and will not execute properly.

🐛 Proposed fix: inline the eval without nested it

-  it('inlined scripts should not have syntax error', () => {
-    eval(manifest['/app-service.js']);
-    eval(manifest['/foo.js']);
-  });
+  // Verify inlined scripts have no syntax errors
+  eval(manifest['/app-service.js']);
+  eval(manifest['/foo.js']);

🤖 Fix all issues with AI agents

In
`@packages/webpack/template-webpack-plugin/test/cases/inline-scripts/external/index.js`:
- Around line 54-56: The nested it() inside the existing test is invalid; remove
the inner it('inlined scripts should not have syntax error', ...) wrapper and
move the eval(manifest['/app-service.js']); call directly into the outer test
body (the outer it that currently contains the nested it), so the eval runs as
part of the existing test rather than as a nested test.

In
`@packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-fn/index.js`:
- Around line 71-73: The nested it('inlined scripts should not have syntax
error') inside the outer it('should generate correct bar template') must be
removed; instead, inline the assertion in the outer test or move it to a new
top-level test. Replace the inner it block with a direct assertion such as
expect(() => eval(manifest['/app-service.js'])).not.toThrow() (or simply call
eval(manifest['/app-service.js']) directly) so the syntax-check runs during the
outer test, or extract that expect(...) into its own top-level it(...) with the
name 'inlined scripts should not have syntax error'.

In
`@packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-object/index.js`:
- Around line 71-73: The test contains a nested it() call inside another it()
which is invalid; remove the inner it('inlined scripts should not have syntax
error', ...) wrapper and instead execute eval(manifest['/app-service.js'])
directly inside the outer test (or lift the inner it block to a separate
top-level test); update the block referencing manifest['/app-service.js'] so the
eval is run inline rather than wrapped in a nested it().

In
`@packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-regex/index.js`:
- Around line 71-73: The test contains a nested it() — specifically the inner
it('inlined scripts should not have syntax error') that calls
eval(manifest['/app-service.js']) is placed inside the outer it('should generate
correct bar template') and will be ignored; fix by removing the nested it and
either inline the assertion (call eval(manifest['/app-service.js']) directly
inside the outer it) or move the inner it to be a sibling test at the top level
so that eval(manifest['/app-service.js']) runs as its own test.

In
`@packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline/index.js`:
- Around line 43-45: The test contains a nested it() call ("inlined scripts
should not have syntax error") inside the outer it("should generate correct foo
template"), which Vitest ignores; remove the inner it() wrapper and inline its
assertion into the outer test body by replacing the nested block with a direct
call to eval(manifest['/app-service.js']); so the syntax check runs as part of
the "should generate correct foo template" test.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9de99b0 and 12a75f2.

📒 Files selected for processing (10)

• .changeset/silent-actors-marry.md
• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts
• packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts
• packages/webpack/template-webpack-plugin/test/basic.test.ts
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/external/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-fn/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-object/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-partial/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-regex/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline/index.js

🧰 Additional context used

📓 Path-based instructions (2)

**/*.{js,ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

**/*.{js,ts,tsx}: Follow eslint rules as configured in eslint.config.js including React and TypeScript specific rules
Follow code formatting rules specified in .dprint.jsonc and biome.jsonc

Files:

• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-partial/index.js
• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-regex/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-object/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-fn/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/external/index.js
• packages/webpack/template-webpack-plugin/test/basic.test.ts
• packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts

**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

Use TypeScript in strict mode with the configuration specified in tsconfig.json

Files:

• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts
• packages/webpack/template-webpack-plugin/test/basic.test.ts
• packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts

🧠 Learnings (31)

📓 Common learnings

Learnt from: colinaaa
Repo: lynx-family/lynx-stack PR: 1917
File: packages/mcp-servers/devtool-mcp-server/tsconfig.json:8-8
Timestamp: 2025-11-06T01:19:23.670Z
Learning: The lynx-js/devtool-mcp-server package in lynx-family/lynx-stack targets Node.js >=18.19 (specified in its package.json engines), which is different from the root project's requirement of Node.js ^22 || ^24. The package uses "lib": ["ES2024.Promise"] in its tsconfig.json because it manually includes polyfills for Promise.withResolvers while maintaining compatibility with Node.js v18.

Learnt from: upupming
Repo: lynx-family/lynx-stack PR: 1370
File: packages/webpack/template-webpack-plugin/src/LynxCacheEventsSetupListRuntimeModule.ts:21-25
Timestamp: 2025-08-19T12:49:05.875Z
Learning: In the Lynx cache events system, there are two separate runtime modules with distinct responsibilities: `LynxCacheEventsSetupListRuntimeModule` is only responsible for initializing the setup list with the setup functions, while `LynxCacheEventsRuntimeModule` guarantees the initialization of `loaded` and `cachedActions` properties. The modules have a dependency relationship where `lynxCacheEventsSetupList` is required by `lynxCacheEvents`.

Learnt from: upupming
Repo: lynx-family/lynx-stack PR: 1616
File: packages/webpack/cache-events-webpack-plugin/test/cases/not-cache-events/lazy-bundle/index.js:3-3
Timestamp: 2025-08-27T12:42:01.095Z
Learning: In webpack, properties like __webpack_require__.lynx_ce are injected during compilation/build time when webpack processes modules and generates bundles, not at runtime when dynamic imports execute. Tests for such properties don't need to wait for dynamic imports to complete.

Learnt from: upupming
Repo: lynx-family/lynx-stack PR: 1370
File: packages/webpack/cache-events-webpack-plugin/src/LynxCacheEventsRuntimeModule.ts:23-27
Timestamp: 2025-08-21T08:46:54.494Z
Learning: In Lynx webpack runtime modules, the team prioritizes performance and simplicity over defensive runtime error handling. They prefer relying on compile-time type safety (TypeScript) rather than adding runtime checks like try-catch blocks or type validation, especially for performance-critical code like cache event setup/cleanup functions.

Learnt from: PupilTong
Repo: lynx-family/lynx-stack PR: 1834
File: packages/web-platform/web-worker-runtime/src/backgroundThread/background-apis/createChunkLoading.ts:162-171
Timestamp: 2025-09-25T14:03:25.576Z
Learning: In the lynx-stack codebase, for loadScriptAsync implementations in createChunkLoading.ts, unhandled promise rejections from readScriptAsync are intentionally not caught - the caller is expected to handle errors rather than the loadScriptAsync method itself invoking the callback with error messages.

Learnt from: upupming
Repo: lynx-family/lynx-stack PR: 1370
File: packages/rspeedy/plugin-react/src/entry.ts:237-240
Timestamp: 2025-08-12T09:32:01.512Z
Learning: The events-cache.js functionality for caching events until background threads are ready is manually tested due to the complexity of constructing automated runtime test cases that involve timing, chunk loading, and browser runtime behavior.

Learnt from: gaoachao
Repo: lynx-family/lynx-stack PR: 1736
File: .changeset/spotty-experts-smoke.md:1-3
Timestamp: 2025-09-12T09:43:04.847Z
Learning: In the lynx-family/lynx-stack repository, private packages (marked with "private": true in package.json) like lynx-js/react-transform don't require meaningful changeset entries even when their public APIs change, since they are not published externally and only affect internal development.

Learnt from: colinaaa
Repo: lynx-family/lynx-stack PR: 1330
File: .changeset/olive-animals-attend.md:1-3
Timestamp: 2025-07-22T09:26:16.722Z
Learning: In the lynx-family/lynx-stack repository, CI checks require changesets when files matching the pattern "src/**" are modified (as configured in .changeset/config.json). For internal changes that don't need meaningful changesets, an empty changeset file is used to satisfy the CI requirement while not generating any release notes.

Learnt from: colinaaa
Repo: lynx-family/lynx-stack PR: 1330
File: .changeset/olive-animals-attend.md:1-3
Timestamp: 2025-07-22T09:23:07.797Z
Learning: In the lynx-family/lynx-stack repository, changesets are only required for meaningful changes to end-users such as bugfixes and features. Internal/development changes like chores, refactoring, or removing debug info do not need changeset entries.

Learnt from: gaoachao
Repo: lynx-family/lynx-stack PR: 1736
File: .changeset/spotty-experts-smoke.md:1-3
Timestamp: 2025-09-12T09:43:04.847Z
Learning: In the lynx-family/lynx-stack repository, empty changeset files (containing only `---\n\n---`) are used for internal changes that modify src/** files but don't require meaningful release notes, such as private package changes or testing-only modifications. This satisfies CI requirements without generating user-facing release notes.

📚 Learning: 2025-08-27T12:42:01.095Z

Learnt from: upupming
Repo: lynx-family/lynx-stack PR: 1616
File: packages/webpack/cache-events-webpack-plugin/test/cases/not-cache-events/lazy-bundle/index.js:3-3
Timestamp: 2025-08-27T12:42:01.095Z
Learning: In webpack, properties like __webpack_require__.lynx_ce are injected during compilation/build time when webpack processes modules and generates bundles, not at runtime when dynamic imports execute. Tests for such properties don't need to wait for dynamic imports to complete.

Applied to files:

• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-partial/index.js
• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts
• .changeset/silent-actors-marry.md
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-regex/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-object/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-fn/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/external/index.js
• packages/webpack/template-webpack-plugin/test/basic.test.ts
• packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts

📚 Learning: 2025-12-29T11:26:09.502Z

Learnt from: CR
Repo: lynx-family/lynx-stack PR: 0
File: packages/web-platform/web-elements/AGENTS.md:0-0
Timestamp: 2025-12-29T11:26:09.502Z
Learning: Applies to packages/web-platform/web-elements/tests/**/*.spec.ts : Use Playwright for all E2E and functional tests with standard assertions like `expect(locator).toBeVisible()`, `expect(locator).toHaveCSS()`, and `diffScreenShot` for screenshot comparisons

Applied to files:

• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-partial/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-regex/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-object/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline/index.js
• packages/webpack/template-webpack-plugin/test/basic.test.ts

📚 Learning: 2025-12-29T11:26:09.502Z

Learnt from: CR
Repo: lynx-family/lynx-stack PR: 0
File: packages/web-platform/web-elements/AGENTS.md:0-0
Timestamp: 2025-12-29T11:26:09.502Z
Learning: Applies to packages/web-platform/web-elements/tests/**/*.spec.ts : When a component makes external requests (e.g., via `iframe` or `fetch`), mock them using `page.route` in Playwright tests to ensure tests are hermetic and fast

Applied to files:

• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-partial/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/external/index.js
• packages/webpack/template-webpack-plugin/test/basic.test.ts

📚 Learning: 2025-08-21T08:46:54.494Z

Learnt from: upupming
Repo: lynx-family/lynx-stack PR: 1370
File: packages/webpack/cache-events-webpack-plugin/src/LynxCacheEventsRuntimeModule.ts:23-27
Timestamp: 2025-08-21T08:46:54.494Z
Learning: In Lynx webpack runtime modules, the team prioritizes performance and simplicity over defensive runtime error handling. They prefer relying on compile-time type safety (TypeScript) rather than adding runtime checks like try-catch blocks or type validation, especially for performance-critical code like cache event setup/cleanup functions.

Applied to files:

• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts
• .changeset/silent-actors-marry.md
• packages/webpack/template-webpack-plugin/test/basic.test.ts
• packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts

📚 Learning: 2025-09-12T09:43:04.847Z

Learnt from: gaoachao
Repo: lynx-family/lynx-stack PR: 1736
File: .changeset/spotty-experts-smoke.md:1-3
Timestamp: 2025-09-12T09:43:04.847Z
Learning: In the lynx-family/lynx-stack repository, private packages (marked with "private": true in package.json) like lynx-js/react-transform don't require meaningful changeset entries even when their public APIs change, since they are not published externally and only affect internal development.

Applied to files:

• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts
• .changeset/silent-actors-marry.md
• packages/webpack/template-webpack-plugin/test/basic.test.ts
• packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts

📚 Learning: 2025-11-06T01:19:23.670Z

Learnt from: colinaaa
Repo: lynx-family/lynx-stack PR: 1917
File: packages/mcp-servers/devtool-mcp-server/tsconfig.json:8-8
Timestamp: 2025-11-06T01:19:23.670Z
Learning: The lynx-js/devtool-mcp-server package in lynx-family/lynx-stack targets Node.js >=18.19 (specified in its package.json engines), which is different from the root project's requirement of Node.js ^22 || ^24. The package uses "lib": ["ES2024.Promise"] in its tsconfig.json because it manually includes polyfills for Promise.withResolvers while maintaining compatibility with Node.js v18.

Applied to files:

• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts
• .changeset/silent-actors-marry.md
• packages/webpack/template-webpack-plugin/test/basic.test.ts
• packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts

📚 Learning: 2025-08-07T04:00:59.645Z

Learnt from: colinaaa
Repo: lynx-family/lynx-stack PR: 1454
File: pnpm-workspace.yaml:46-46
Timestamp: 2025-08-07T04:00:59.645Z
Learning: In the lynx-family/lynx-stack repository, the webpack patch (patches/webpack5.101.0.patch) was created to fix issues with webpack5.99.9 but only takes effect on webpack5.100.0 and later versions. The patchedDependencies entry should use "webpack@^5.100.0" to ensure the patch applies to the correct version range.

Applied to files:

• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts
• .changeset/silent-actors-marry.md
• packages/webpack/template-webpack-plugin/test/basic.test.ts
• packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts

📚 Learning: 2025-12-26T05:10:01.608Z

Learnt from: CR
Repo: lynx-family/lynx-stack PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-26T05:10:01.608Z
Learning: Applies to packages/react/components/**/*.{ts,tsx} : Optimize component library in packages/react/components/ using ReactLynx syntax

Applied to files:

• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts
• packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts

📚 Learning: 2025-08-13T11:46:43.737Z

Learnt from: colinaaa
Repo: lynx-family/lynx-stack PR: 1523
File: vitest.config.ts:5-6
Timestamp: 2025-08-13T11:46:43.737Z
Learning: In the lynx-stack codebase, default imports are consistently used for Node.js built-in modules (e.g., `import os from 'node:os'`, `import fs from 'node:fs'`). The TypeScript configuration supports esModuleInterop and allowSyntheticDefaultImports, making default imports the preferred pattern over namespace imports for Node.js built-ins.

Applied to files:

• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts
• .changeset/silent-actors-marry.md
• packages/webpack/template-webpack-plugin/test/basic.test.ts
• packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts

📚 Learning: 2025-09-18T04:43:54.426Z

Learnt from: gaoachao
Repo: lynx-family/lynx-stack PR: 1771
File: packages/react/transform/tests/__swc_snapshots__/src/swc_plugin_snapshot/mod.rs/basic_component_with_static_sibling.js:2-2
Timestamp: 2025-09-18T04:43:54.426Z
Learning: In the lynx-family/lynx-stack repository, the `add_pure_comment` function in packages/react/transform/src/swc_plugin_compat/mod.rs (around lines 478-482) is specifically for `wrapWithLynxComponent` calls, not `createSnapshot` calls. The PURE comment injection for `createSnapshot` is handled separately in swc_plugin_snapshot/mod.rs.

Applied to files:

• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts

📚 Learning: 2025-08-12T16:09:32.413Z

Learnt from: colinaaa
Repo: lynx-family/lynx-stack PR: 1497
File: packages/react/transform/tests/__swc_snapshots__/src/swc_plugin_snapshot/mod.rs/basic_full_static.js:9-10
Timestamp: 2025-08-12T16:09:32.413Z
Learning: In the Lynx stack, functions prefixed with `__` that are called in transformed code may be injected globally by the Lynx Engine at runtime rather than exported from the React runtime package. For example, `__CreateFrame` is injected globally by the Lynx Engine, not exported from lynx-js/react.

Applied to files:

• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts
• packages/webpack/template-webpack-plugin/test/basic.test.ts
• packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts

📚 Learning: 2025-08-13T11:36:12.075Z

Learnt from: colinaaa
Repo: lynx-family/lynx-stack PR: 1523
File: vitest.config.ts:52-72
Timestamp: 2025-08-13T11:36:12.075Z
Learning: The lynx-stack project requires Node.js >=22 as specified in package.json engines, so Node.js compatibility fallbacks for features introduced before v22 are unnecessary.

Applied to files:

• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts
• .changeset/silent-actors-marry.md
• packages/webpack/template-webpack-plugin/test/basic.test.ts

📚 Learning: 2025-09-25T14:03:25.576Z

Learnt from: PupilTong
Repo: lynx-family/lynx-stack PR: 1834
File: packages/web-platform/web-worker-runtime/src/backgroundThread/background-apis/createChunkLoading.ts:162-171
Timestamp: 2025-09-25T14:03:25.576Z
Learning: In the lynx-stack codebase, for loadScriptAsync implementations in createChunkLoading.ts, unhandled promise rejections from readScriptAsync are intentionally not caught - the caller is expected to handle errors rather than the loadScriptAsync method itself invoking the callback with error messages.

Applied to files:

• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts
• .changeset/silent-actors-marry.md
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/external/index.js
• packages/webpack/template-webpack-plugin/test/basic.test.ts
• packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts

📚 Learning: 2025-08-27T08:10:09.932Z

Learnt from: colinaaa
Repo: lynx-family/lynx-stack PR: 1612
File: packages/rspeedy/create-rspeedy/template-react-vitest-rltl-ts/src/tsconfig.json:3-13
Timestamp: 2025-08-27T08:10:09.932Z
Learning: In the lynx-family/lynx-stack repository, Rspeedy templates use `lynx-js/rspeedy/client` types via `rspeedy-env.d.ts` instead of `vite/client` types. Rspeedy provides its own client-side environment type definitions and doesn't require direct Vite type references.

Applied to files:

• packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts

📚 Learning: 2025-09-12T09:43:04.847Z

Learnt from: gaoachao
Repo: lynx-family/lynx-stack PR: 1736
File: .changeset/spotty-experts-smoke.md:1-3
Timestamp: 2025-09-12T09:43:04.847Z
Learning: In the lynx-family/lynx-stack repository, empty changeset files (containing only `---\n\n---`) are used for internal changes that modify src/** files but don't require meaningful release notes, such as private package changes or testing-only modifications. This satisfies CI requirements without generating user-facing release notes.

Applied to files:

• .changeset/silent-actors-marry.md

📚 Learning: 2025-07-22T09:26:16.722Z

Learnt from: colinaaa
Repo: lynx-family/lynx-stack PR: 1330
File: .changeset/olive-animals-attend.md:1-3
Timestamp: 2025-07-22T09:26:16.722Z
Learning: In the lynx-family/lynx-stack repository, CI checks require changesets when files matching the pattern "src/**" are modified (as configured in .changeset/config.json). For internal changes that don't need meaningful changesets, an empty changeset file is used to satisfy the CI requirement while not generating any release notes.

Applied to files:

• .changeset/silent-actors-marry.md

📚 Learning: 2025-07-22T09:23:07.797Z

Learnt from: colinaaa
Repo: lynx-family/lynx-stack PR: 1330
File: .changeset/olive-animals-attend.md:1-3
Timestamp: 2025-07-22T09:23:07.797Z
Learning: In the lynx-family/lynx-stack repository, changesets are only required for meaningful changes to end-users such as bugfixes and features. Internal/development changes like chores, refactoring, or removing debug info do not need changeset entries.

Applied to files:

• .changeset/silent-actors-marry.md

📚 Learning: 2025-12-26T05:10:01.608Z

Learnt from: CR
Repo: lynx-family/lynx-stack PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-26T05:10:01.608Z
Learning: Use changeset tool with `pnpm changeset` to document changes before contribution

Applied to files:

• .changeset/silent-actors-marry.md

📚 Learning: 2025-09-23T08:53:56.927Z

Learnt from: upupming
Repo: lynx-family/lynx-stack PR: 1670
File: packages/webpack/css-extract-webpack-plugin/src/loader.ts:244-251
Timestamp: 2025-09-23T08:53:56.927Z
Learning: In webpack CSS extraction plugins, when storing per-module dependencies in a compiler-scoped map like cssModuleId2Deps, the map should not be reset at compilation start because in incremental compilation (watch mode/HMR), only changed files pass through the loader. Unchanged modules need their dependency information to persist between compilations so the plugin can access all modules' dependencies when generating CSS output.

Applied to files:

• .changeset/silent-actors-marry.md

📚 Learning: 2025-09-23T08:54:39.966Z

Learnt from: upupming
Repo: lynx-family/lynx-stack PR: 1670
File: packages/webpack/css-extract-webpack-plugin/test/hotCases/hot/hot-update-json/dual-thread/__snapshot__/index.css:6-8
Timestamp: 2025-09-23T08:54:39.966Z
Learning: In the lynx-stack CSS extract webpack plugin tests, many test fixture CSS files intentionally use invalid CSS syntax like `color: 'red';` with quoted values. The snapshots correctly reflect this invalid CSS from the source fixtures. To fix CSS validation issues, the source fixture files should be updated first, then snapshots regenerated, rather than manually editing snapshots.

Applied to files:

• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-regex/index.js
• packages/webpack/template-webpack-plugin/test/basic.test.ts

📚 Learning: 2025-12-26T05:10:01.608Z

Learnt from: CR
Repo: lynx-family/lynx-stack PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-26T05:10:01.608Z
Learning: Applies to packages/web-platform/web-tests/**/*.{ts,tsx,js} : Use Playwright for E2E tests in packages/web-platform/web-tests/

Applied to files:

• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline/index.js
• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/external/index.js
• packages/webpack/template-webpack-plugin/test/basic.test.ts

📚 Learning: 2025-08-14T06:51:39.827Z

Learnt from: upupming
Repo: lynx-family/lynx-stack PR: 1370
File: packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts:160-171
Timestamp: 2025-08-14T06:51:39.827Z
Learning: In the LynxEncodePlugin for events-cache.js functionality, when iterating through entrypoints to find background scripts, any entry .js file that exists in the manifest is guaranteed to be the background.js needed by design. The manifest generation logic ensures only background scripts from entrypoints are included, making the simple "first .js file in manifest" selection approach correct and reliable.

Applied to files:

• packages/webpack/template-webpack-plugin/test/cases/inline-scripts/external/index.js

📚 Learning: 2025-12-29T11:26:09.502Z

Learnt from: CR
Repo: lynx-family/lynx-stack PR: 0
File: packages/web-platform/web-elements/AGENTS.md:0-0
Timestamp: 2025-12-29T11:26:09.502Z
Learning: Applies to packages/web-platform/web-elements/tests/**/*.spec.ts : Create a separate spec file for new components (e.g., `tests/x-webview.spec.ts`) instead of adding to the monolithic `web-elements.spec.ts`

Applied to files:

• packages/webpack/template-webpack-plugin/test/basic.test.ts

📚 Learning: 2025-10-29T10:28:27.519Z

Learnt from: upupming
Repo: lynx-family/lynx-stack PR: 1899
File: packages/react/transform/crates/swc_plugin_snapshot/tests/__swc_snapshots__/lib.rs/should_static_extract_dynamic_inline_style.js:20-24
Timestamp: 2025-10-29T10:28:27.519Z
Learning: Files inside packages/react/transform/crates/swc_plugin_snapshot/tests/__swc_snapshots__/ are auto-generated test snapshot files and should not be manually updated. Any issues with the generated code should be addressed in the code generator/transform logic, not in the snapshots themselves.

Applied to files:

• packages/webpack/template-webpack-plugin/test/basic.test.ts

📚 Learning: 2025-12-26T05:10:01.608Z

Learnt from: CR
Repo: lynx-family/lynx-stack PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-26T05:10:01.608Z
Learning: Applies to **/__test__/**/*.{ts,tsx,js} : Use vitest-based unit tests as configured in vitest.config.ts

Applied to files:

• packages/webpack/template-webpack-plugin/test/basic.test.ts

📚 Learning: 2025-12-29T11:26:09.502Z

Learnt from: CR
Repo: lynx-family/lynx-stack PR: 0
File: packages/web-platform/web-elements/AGENTS.md:0-0
Timestamp: 2025-12-29T11:26:09.502Z
Learning: Applies to packages/web-platform/web-elements/src/elements/all.ts : Export new components in `src/elements/all.ts` and add export configuration to `package.json` under `exports` for both types and default

Applied to files:

• packages/webpack/template-webpack-plugin/test/basic.test.ts

📚 Learning: 2025-12-26T05:10:01.608Z

Learnt from: CR
Repo: lynx-family/lynx-stack PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-26T05:10:01.608Z
Learning: Applies to packages/rspeedy/plugin-*/**/*.{ts,tsx,js} : Configure build plugins using the plugin architecture in packages/rspeedy/plugin-*/

Applied to files:

• packages/webpack/template-webpack-plugin/test/basic.test.ts

📚 Learning: 2025-08-19T12:49:05.875Z

Learnt from: upupming
Repo: lynx-family/lynx-stack PR: 1370
File: packages/webpack/template-webpack-plugin/src/LynxCacheEventsSetupListRuntimeModule.ts:21-25
Timestamp: 2025-08-19T12:49:05.875Z
Learning: In the Lynx cache events system, there are two separate runtime modules with distinct responsibilities: `LynxCacheEventsSetupListRuntimeModule` is only responsible for initializing the setup list with the setup functions, while `LynxCacheEventsRuntimeModule` guarantees the initialization of `loaded` and `cachedActions` properties. The modules have a dependency relationship where `lynxCacheEventsSetupList` is required by `lynxCacheEvents`.

Applied to files:

• packages/webpack/template-webpack-plugin/test/basic.test.ts
• packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts

📚 Learning: 2025-08-12T09:32:01.512Z

Learnt from: upupming
Repo: lynx-family/lynx-stack PR: 1370
File: packages/rspeedy/plugin-react/src/entry.ts:237-240
Timestamp: 2025-08-12T09:32:01.512Z
Learning: The events-cache.js functionality for caching events until background threads are ready is manually tested due to the complexity of constructing automated runtime test cases that involve timing, chunk loading, and browser runtime behavior.

Applied to files:

• packages/webpack/template-webpack-plugin/test/basic.test.ts

📚 Learning: 2025-08-11T05:57:18.212Z

Learnt from: upupming
Repo: lynx-family/lynx-stack PR: 1305
File: packages/testing-library/testing-environment/src/index.ts:255-258
Timestamp: 2025-08-11T05:57:18.212Z
Learning: In the ReactLynx testing environment (`packages/testing-library/testing-environment/src/index.ts`), the dual assignment pattern `target.console.method = console.method = () => {}` is required for rstest compatibility. This is because rstest provides `console` in an IIFE (Immediately Invoked Function Expression), and both the target and global console need to have these methods defined for proper test execution.

Applied to files:

• packages/webpack/template-webpack-plugin/test/basic.test.ts

🧬 Code graph analysis (3)

packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts (1)

packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts (1)

• getRequireModuleAsyncCachePolyfill (19-51)

packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-fn/index.js (1)

packages/web-platform/playwright-fixtures/src/coverage-fixture.ts (1)

• expect (76-76)

packages/webpack/template-webpack-plugin/test/basic.test.ts (1)

packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts (1)

• getRequireModuleAsyncCachePolyfill (19-51)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: build / Build (Windows)
• GitHub Check: build / Build (Ubuntu)
• GitHub Check: test-rust / Test (Ubuntu)

🔇 Additional comments (13)

packages/webpack/template-webpack-plugin/src/polyfill/requireModuleAsync.ts (1)

19-51: LGTM! Clean polyfill implementation.

The caching logic correctly handles:

• Immediate return for completed requests (status 2)
• Queuing callbacks for in-progress requests (status 1)
• Clearing callbacks after completion to prevent memory leaks

The use of var is appropriate for runtime injection compatibility.

packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-object/index.js (1)

63-64: Good assertion for polyfill presence.

This correctly verifies that the requireModuleAsyncCache polyfill is injected into the app-service manifest.

.changeset/silent-actors-marry.md (1)

1-5: LGTM!

Changeset is correctly formatted with an appropriate patch-level bump. The description accurately summarizes the new polyfill functionality.

packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-partial/index.js (1)

28-29: Good assertion for polyfill presence.

Correctly verifies the requireModuleAsyncCache polyfill is included in the manifest.

packages/webpack/template-webpack-plugin/test/cases/inline-scripts/external/index.js (1)

43-44: Good assertion for polyfill presence.

Correctly verifies the requireModuleAsyncCache polyfill is included when external assets are present.

packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-fn/index.js (1)

63-64: LGTM!

The assertion correctly validates that the polyfill containing moduleCache initialization is present in the generated app-service script.

packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline-regex/index.js (1)

63-64: LGTM!

Polyfill presence assertion is correctly added.

packages/webpack/template-webpack-plugin/test/cases/inline-scripts/inline/index.js (1)

33-36: LGTM!

The assertion correctly validates that the polyfill is not present when there are no external assets (all chunks are inlined). This aligns with the logic in LynxEncodePlugin.ts that only injects the polyfill when externalKeys.length > 0.

packages/webpack/template-webpack-plugin/src/LynxEncodePlugin.ts (2)

8-8: LGTM!

Import correctly added for the polyfill function.

---

256-258: LGTM!

The polyfill is correctly injected only when there are external assets (externalKeys.length > 0), and it's placed before the requireModuleAsync calls to ensure the caching wrapper is in place before any module requests. The implementation aligns with the PR objective of caching identical parallel requests.

packages/webpack/template-webpack-plugin/test/basic.test.ts (3)

10-10: LGTM!

Import correctly added for the polyfill function to test it directly.

---

75-113: LGTM!

The test setup creates a well-designed mock of lynx.requireModuleAsync that:

1. Simulates async module loading with setTimeout
2. Tracks evaluation counts per module
3. Includes both success and error test cases

The type assertion for the function with a cache property is a pragmatic approach for testing.

---

115-148: Comprehensive test coverage for the polyfill behavior.

The tests correctly verify:

1. Default behavior without polyfill (parallel calls trigger multiple evaluations)
2. With polyfill applied, parallel calls for the same module only evaluate once
3. Error handling propagates to all callbacks

One minor observation: the setTimeout(resolve, 0) pattern relies on macrotask timing, which should work reliably for this simple case. If flakiness occurs in CI, consider using vi.useFakeTimers() for deterministic timing control.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}