Add Module Loader#47
Conversation
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new Module Loader protocol and its implementation across three packages: a common package for shared types, a runner-side plugin to request and register modules, and a web-side plugin to fetch the module directory and serve module bundles. The feedback highlights critical improvements needed for protocol robustness and safety, including adding moduleName to response messages to prevent race conditions, handling potential promise rejections in asynchronous operations (such as dynamic imports and fetch requests), and securing the module name validation regex with anchors to prevent path traversal or input validation bypasses.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| error: "Module directory not loaded yet", | ||
| }); | ||
| } | ||
| if (!(message.moduleName in this.moduleDirectory)) { |
There was a problem hiding this comment.
Module-existence check uses the in operator (!(message.moduleName in this.moduleDirectory)) against a plain JSON-parsed object, which walks the prototype chain. Requesting moduleName: "toString" (or "constructor") passes both this check and the ^[a-zA-Z0-9_-]+$ regex at line 50, then this.moduleDirectory["toString"].tabs (line 65) resolves to Object.prototype.toString, whose .tabs is undefined. A MODULE_RESPONSE goes out with tabs: undefined, violating the declared tabs: string[] contract — and the runner's loadTab (src/runner/module-loader/src/index.ts:48, msg.tabs.includes(tabName)) throws TypeError: Cannot read properties of undefined (reading 'includes') the first time a tab is loaded. Independently flagged by three separate finder passes.
There was a problem hiding this comment.
Will this disrupt the working of other plugins and packages in this repo? Its a high-blast-radius tooling change riding along on a feature PR.
| if (newURL === this.moduleDirectoryURL && this.moduleDirectory) { | ||
| return; | ||
| } | ||
| this.moduleDirectoryURL = newURL; |
There was a problem hiding this comment.
onModuleDirectoryURLChange sets this.moduleDirectoryURL = newURL (line 74) synchronously, before the fetch resolves. Two consequences: (a) two rapid calls with the same URL both pass the dedup guard (line 71, this.moduleDirectory is still null on the second call) and both fire redundant fetches; (b) if the fetch fails, the URL is already recorded as "current," so a later retry with that same URL short-circuits at line 71 and never actually re-fetches — the directory is permanently stuck stale/empty for that URL.
There was a problem hiding this comment.
Could you give an example of onModuleDirectoryURLChange being called two times in a short span? That seems very improbable. For point b), I'll make the change
| }; | ||
| this.__moduleRequestChannel.subscribe(handleResponse); | ||
| this.__moduleRequestChannel.send({ | ||
| type: ModuleLoaderMessageType.REQUEST_MODULE, | ||
| moduleName, |
There was a problem hiding this comment.
Two concurrent requestModule("chart") calls each subscribe their own handleResponse (line 64). If the underlying IChannel broadcasts one response to all subscribers, both listeners pass the moduleName filter (line 39) and both proceed to registerPlugin/initialise — double-registering the same module. (Plausible, contingent on the real IChannel supporting multiple simultaneous subscribers — worth confirming against the conductor implementation.)
There was a problem hiding this comment.
requestModule should never be called twice with the same value, it's the equivalent of calling registerPlugin twice. I guess I could add a check to ensure this doesn't happen
| } | ||
| const moduleBaseUrl = this.moduleDirectoryURL.slice( | ||
| 0, | ||
| this.moduleDirectoryURL.lastIndexOf("/") + 1, |
There was a problem hiding this comment.
moduleBaseUrl derivation assumes moduleDirectoryURL contains a /. A directory URL with none (e.g. a bare "modules.json") makes lastIndexOf("/") return -1, so moduleBaseUrl becomes ""
| { | ||
| "name": "@sourceacademy/runner-module-loader", | ||
| "version": "0.0.1", | ||
| "packageManager": "yarn@4.12.0", |
There was a problem hiding this comment.
The two sibling packages added in this same PR pin yarn@4.6.0.
Any reason for the discreptancy?
2 participants
This pull request introduces a new pluginset to load Source Academy modules via Conductor plugins. It adds three new packages,
@sourceacademy/common-module-loader,@sourceacademy/runner-module-loader, and@sourceacademy/web-module-loader. It also reverts the repository to Yarn PnP