Add multi-entry self-hosted dependencies to eliminate singleton hazard - #74
Merged
Conversation
Registering several subpaths of the same workspace package as separate
dependencies bundled each subpath in its own tsdown build, so shared
modules (e.g. component classes referenced by both a barrel and a lazy
manifest) were duplicated across bundles into distinct module instances
— a singleton/identity hazard for class-keyed registries and instanceof.
Add an `entries` map to `DependencyConfig` keyed by export subpath
(`.`, `./manifest`, …). All entries of a package are now built together
in a single code-split tsdown build: shared modules become one shared
chunk referenced by every entry, giving a single runtime instance.
Each entry is emitted verbatim under the base `static/deps/<specifier>/`
directory (the `.` entry keeps the `index.js` name for back-compat, other
subpaths use `<name>.js`), so the entries' relative import/import() of the
shared chunks resolve unchanged with no rewriting. Import-map entries and
`_headers` x-typescript-types lines are generated per subpath.
Single-entry `{ specifier, source, entry }` and esm.sh forms are
unchanged. Covers the fix with a real tsdown build asserting the shared
module is emitted once and referenced by both a static-import barrel and a
dynamic-import manifest, plus resolution/prefixing unit tests, and a
multi-entry demo-lib config exercising the whole webpack pipeline.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014FQxYGj2RqgcP8BkubpiNu
Deploying studiometa-playground with
|
| Latest commit: |
b7be27e
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://a21f8055.studiometa-playground.pages.dev |
| Branch Preview URL: | https://feat-multi-entry-dependencie.studiometa-playground.pages.dev |
|
Size Change: +1.28 kB (+2.51%) Total Size: 52.1 kB 📦 View Changed
ℹ️ View Unchanged
|
Codecov Report❌ Patch coverage is ❌ Your patch check has failed because the patch coverage (74.54%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #74 +/- ##
==========================================
+ Coverage 27.89% 29.96% +2.06%
==========================================
Files 55 55
Lines 993 1038 +45
Branches 190 203 +13
==========================================
+ Hits 277 311 +34
- Misses 702 709 +7
- Partials 14 18 +4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This was referenced Aug 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
PlaygroundDependenciesPluginbundles each self-hosted dependency as its own tsdown build (oneentry→ one bundle atstatic/deps/<specifier>/). When a consumer registers multiple subpaths of the same workspace package as separate dependencies — e.g.@studiometa/ui(barrel) and@studiometa/ui/manifest(lazy) — each build independently bundles the shared modules (the ui component classes).Result: the barrel's
Actionclass and the manifest-lazy-loadedActionclass are different module instances → a singleton/identity hazard. js-toolkit's component registry is keyed by class/name,instanceofbreaks, and a component imported via the barrel is not the one autoloaded via the manifest. js-toolkit itself is fine (externalized to a single esm.sh instance), but the workspace package's own modules get duplicated across its subpath bundles.Fix
Add an
entriesmap toDependencyConfig, keyed by export subpath (Nodeexports-style:.,./manifest, …):All entries are built together in one code-split tsdown build. rolldown hoists the modules shared between entries into a single shared chunk referenced by every entry → one runtime instance, no singleton hazard.
How shared chunks resolve across entries
Each entry is emitted verbatim under the base
static/deps/<specifier>/directory using its rolldown filename:.→index.js(keeps the existing contract) +index.d.ts./manifest→manifest.js+manifest.d.tsgreeter-<hash>.js(emitted once)Because entries and shared chunks live in the same base dir and every chunk keeps the exact filename rolldown assigned, the entries' relative
import/import()of the shared chunks resolve unchanged — no code rewriting. Import-map entries and_headersx-typescript-typeslines are generated per subpath.End-to-end proof (demo build)
The
demo-libconfig is switched to multi-entry (.+./manifest, both using a sharedgreetermodule).npm run demo:buildemits:Import map:
"demo-lib": "…/index.js","demo-lib/manifest": "…/manifest.js"._headershas a line per subpath.Backward compatibility
Single-entry
{ specifier, source, entry }and esm.sh (string /{ specifier }) forms are unchanged. All existing tests remain green.Tests
135 tests pass; build and lint clean.
Release
Would ship as 0.3.12 (patch/minor — additive, backward-compatible). Not published here.
🤖 Generated with Claude Code