Make Container.provides() chain O(N) instead of O(N²)

[kburov-sc]

Background

Long Container.provides() chains used to construct in O(N²) time (per-step {...this.factories} spread + a constructor for...in rebinding every memoized factory's thisArg). Snap mobile team reported ANRs on container assembly for low-end devices, with traces converging on Container.provides. The same shape applied to PartialContainer.

Change

• Construction is O(N) per chain. Replace the spread with Object.create(this.factories) + per-token assignment; drop thisArg mutation in favour of call-site this in memoize. Same treatment in PartialContainer, copy(), and the merge paths.
• Reads stay O(1). A naive Object.create-based chain regressed Container.get() to a prototype-chain walk costing O(depth-of-token) — invisible on V8 (inline caches mask it) but ~20× regression on Hermes per the Snap mobile measurement. Fix: materialize a flat own-property snapshot of factories on the first get() and read from it thereafter.
• Token names that collide with Object.prototype ("toString", "constructor", "__proto__", …) now resolve only if explicitly registered. The factories map is rooted at a null-prototype object so they don't leak through get().

Behavioral note: each container is now a true snapshot — parent.get('svc') after forking a child no longer resolves dependencies through the child (the old thisArg-mutation code did this). Sibling isolation across forks still requires copy(['token']), unchanged.

Numbers

Chain construction:

N	Container before	Container after	PartialContainer before	PartialContainer after
800	32.08 ms	4.27 ms	14.20 ms	2.67 ms
1600	309.44 ms	18.32 ms	134.99 ms	15.90 ms
8000	10,285.6 ms	495.9 ms	5,199.1 ms	512.6 ms

Hot read-path full sweep:

N	without flatten cache	with flatten cache
800	1.883 ms	0.069 ms
1600	13.313 ms	0.103 ms

Full write-up + reproduction steps: benchmarks/INVESTIGATION.md and npm run bench.

Test plan

• npm test — 93/93 passing, 100% line/branch/function/statement coverage.
• npm run compile, npm run styleguide clean.
• npm run bench confirms linear scaling of both construction and reads.

🤖 Generated with Claude Code

[ecoronadosc]

Verified this improves latency until first render requested.

[msilivonik-sc]

Behavioral change worth documenting + testing

This PR changes observable behavior for the following pattern:

const base = Container
  .providesValue("number", 1)
  .provides("app", ["number"], (number) => ({ number }));
base.providesValue("number", 2);          // return value intentionally discarded

console.log(base.get("app"));

Version	Result
Before this PR	{ number: 2 } — creating a child container mutated base's memoized factory via thisArg, so the override leaked back into base
After this PR	{ number: 1 } — providesValue is now fully non-mutating; base is unaffected

The new behavior is clearly correct (and matches the intent described in the old constructor comment), but it's a breaking change for any caller that accidentally relied on the mutation side-effect.

Three asks before merge:

1. Add a regression test for this exact pattern — get() on the parent after a discarded providesValue() call should return the parent's own value, not the child's.

2. Update docs / README anywhere that describes provides/providesValue chaining or child-container semantics — make it explicit that the returned container is the only thing that sees the override, and calling sites that discard the return value get no effect.

No objection to the fix itself — the old behavior was an implementation accident and the new code is the right shape.

[msilivonik-sc]

As per offline converstaion the test already exists! Let's add a note before this line here:

Note: Each registration method (provides, providesValue, providesClass, etc.)
returns a new child container — the original container is never modified.
Always use the returned value; calls whose return value is discarded have no effect.

[msilivonik-sc]

LGTM! Nice change!