⚡️Use prototyped class for ScopeInternal

[cowboyd]

Motivation

The scope implementation was creating a unique prototype for every single scope instance which caused depotimization of every single scope method.

Approach

This extracts all the core methods into a single prototype based class that shares a single implementation among all instances, which allows V8 (and presumably other runtimes) to inline the implementation.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/effection@1184

commit: 83e7bfc

[codspeed-hq]

Merging this PR will improve performance by 15.14%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
✅ 5 untouched benchmarks

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	Memory	effection.events	91.7 KB	79.7 KB	+15.14%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing classify-scope-internal (83e7bfc) with v4 (846b97e)}

[cowboyd]

Pre-merge check: verify Symbol-keyed augmentations still work

The wrapper change moves scope from Object.create({...closures...}) to Object.create(Scope, {own-bound-methods}). Symbol.toStringTag lives on the shared Scope prototype (good), but two Symbol-keyed properties are added after construction by createScope:

• Symbol.iterator — lib/scope.ts:75-78, used for tuple destructuring let [scope, dispose] = createScope()
• Symbol.asyncDispose — lib/scope.ts:80-83, used by await using scope = createScope()

Both rely on Object.defineProperty(scope, ...) succeeding on the returned scope object. Should still work since the wrapper is a plain object, but worth running:

1. A test that destructures createScope() as a tuple
2. A test that uses await using semantics

If both pass on this branch, this comment can be resolved.