|
|
2 ماه پیش | |
|---|---|---|
| .. | ||
| src | 2 ماه پیش | |
| tests | 2 ماه پیش | |
| README.md | 2 ماه پیش | |
| package.json | 2 ماه پیش | |
| tsconfig.json | 2 ماه پیش | |
| tsdown.config.ts | 2 ماه پیش | |
Hot reload for fetch-arrival client plugins. A static-arrival entry composed only into --dev graphs (dsh web --dev); production graphs omit the row, so the shell-bundled code stays inert.
The plugin subscribes to the webserver's system SSE channel (GET /plugins/events) and reloads one plugin per rebuilt frame, serialized through a queue (the bundle handoff slot is single). The sequence per frame — prefetch (fetch the new bundle before touching anything), invalidate, registry.delete (before the fiber: a bare fiber dispose trips the vendored Loader's self-dispose branch, which would mark the entry disabled), drain the old fiber, delete entry.fiber, remove owned <style data-plugin> tags, entry.refresh() re-imports and remounts, fiber.await() rethrows startup failures loud. Dependents reload through cordis itself: a fiber's activation epoch strings its service providers' uids, so replacing a provider's fiber cascades every dependent with zero client-side graph analysis. Rebuild detection lives on the webserver: in dev mode it stat-polls each plugin's built lib/client.js (fs.watchFile) and broadcasts the rebuilt frame when the bundle's rev changes, so any tsdown watch process producing the bundle triggers HMR with no builder→host channel.
None, as the reload driver is browser-side machinery; nothing here reaches a model request.
None; this package neither assembles nor sends a provider request.