[loader] Replace renderer CommonJS dependency handling with catalogue resolver #215

New issue

Closed

opened 2026-06-02 09:43:27 +00:00 by steve · 0 comments

steve commented

2026-06-02 09:43:27 +00:00

Owner

Problem

The renderer CommonJS host currently resolves bare dependencies from a hardcoded object. That compatibility path should use the same generated host-module catalogue as the future ESM path and produce clearer dependency diagnostics.

Goal

Improve CommonJS compatibility with a catalogue-backed dependency resolver while preserving current Obsidian-compatible plugin behavior.

Scope

Add PluginDependencyResolver, PluginDependencyContext, and PluginSharedDependencyInfo contracts.
Add a generated workspace CommonJS resolver from the host module catalogue.
Keep a legacy object resolver adapter for transition compatibility.
Update RendererCommunityPluginExecutionHost to resolve bare specifiers through the resolver while preserving local module graph loading.
Add a conservative dependency scanner for diagnostics and validation.
Improve unknown, private, deprecated, or platform-incompatible dependency messages.

Non-goals

Do not make CommonJS the preferred first-party plugin format.
Do not remove the existing dependency registration compatibility hook until all callers are migrated.
Do not implement ESM plugin loading in this issue.

Acceptance Criteria

Existing Obsidian-compatible plugins still load.
Generated exact specifiers and allowed package-export subpaths resolve correctly.
Unknown, private, deprecated, and platform-incompatible modules produce clear diagnostics.
Undeclared shared dependencies can be detected for warnings or validation.

Implementation Notes

Relative plugin modules should continue to resolve before bare dependency resolution.
Error messages should tell plugin authors whether to bundle the dependency or add it to the host catalogue.
Resolver policy should be host and format aware.

Suggested Files or Specs To Inspect

spec/src/30-cross-package-contracts/plugin-runtime.md
packages/api/src/lib/plugin-manager.ts
packages/workspace/src/lib/deps.ts
packages/workspace/src/lib/generated/

Validation Commands

pnpm plugin-host:check
pnpm --filter @lapis-notes/api check:all
pnpm --filter @lapis-notes/workspace check:all
pnpm check:all

Follow-up Tasks

Implementation Summary

Replaced renderer CommonJS dependency exposure with a catalogue-backed workspace resolver that lists supported shared modules and reports unsupported CommonJS requires with plugin, host, format, and supported-module context.

## Problem The renderer CommonJS host currently resolves bare dependencies from a hardcoded object. That compatibility path should use the same generated host-module catalogue as the future ESM path and produce clearer dependency diagnostics. ## Goal Improve CommonJS compatibility with a catalogue-backed dependency resolver while preserving current Obsidian-compatible plugin behavior. ## Scope - Add `PluginDependencyResolver`, `PluginDependencyContext`, and `PluginSharedDependencyInfo` contracts. - Add a generated workspace CommonJS resolver from the host module catalogue. - Keep a legacy object resolver adapter for transition compatibility. - Update `RendererCommunityPluginExecutionHost` to resolve bare specifiers through the resolver while preserving local module graph loading. - Add a conservative dependency scanner for diagnostics and validation. - Improve unknown, private, deprecated, or platform-incompatible dependency messages. ## Non-goals - Do not make CommonJS the preferred first-party plugin format. - Do not remove the existing dependency registration compatibility hook until all callers are migrated. - Do not implement ESM plugin loading in this issue. ## Acceptance Criteria - Existing Obsidian-compatible plugins still load. - Generated exact specifiers and allowed package-export subpaths resolve correctly. - Unknown, private, deprecated, and platform-incompatible modules produce clear diagnostics. - Undeclared shared dependencies can be detected for warnings or validation. ## Implementation Notes - Relative plugin modules should continue to resolve before bare dependency resolution. - Error messages should tell plugin authors whether to bundle the dependency or add it to the host catalogue. - Resolver policy should be host and format aware. ## Suggested Files or Specs To Inspect - `spec/src/30-cross-package-contracts/plugin-runtime.md` - `packages/api/src/lib/plugin-manager.ts` - `packages/workspace/src/lib/deps.ts` - `packages/workspace/src/lib/generated/` ## Validation Commands - `pnpm plugin-host:check` - `pnpm --filter @lapis-notes/api check:all` - `pnpm --filter @lapis-notes/workspace check:all` - `pnpm check:all` ## Related Issues ## Follow-up Tasks ## Implementation Summary Replaced renderer CommonJS dependency exposure with a catalogue-backed workspace resolver that lists supported shared modules and reports unsupported CommonJS requires with plugin, host, format, and supported-module context.

steve added this to the Dual ESM/CJS plugin loader milestone

2026-06-02 09:43:27 +00:00

steve

2026-06-02 09:43:27 +00:00