v4.1.0

Cocoar.JsEval v4.1.0

Wolverine 6 / static-analysis friendly. JsEngine is now constructor-pure and registered type-based — apps on Wolverine 6's strict ServiceLocationPolicy.NotAllowed default can inject JsEngine into handlers without per-consumer AlwaysUseServiceLocationFor<T> allowlist entries. The only service that still needs an explicit allowlist entry is IJsModuleBuilder — a single, intentional locator boundary, instead of a transitive chain through every consumer.

Added

• IJsModuleBuilder / JsModuleBuilder in Cocoar.JsEval — owns the IServiceProvider-based module activation (constructor-parameter resolution via DI + ActivatorUtilities). Registered scoped by AddJsEval. The single intentional locator boundary in the package.

Changed

• JsEngine constructor — JsEngine(IJsModuleRegistry, IJsModuleBuilder, JsEngineOptions, ILogger<JsEngine>?). No more IServiceProvider. Only direct new JsEngine(...) callers need to update.
• IJsModuleRegistry reduced to GetRegisteredModuleDefinitions(). The BuildModuleInstance / BuildSingleModuleInstance methods moved to IJsModuleBuilder. TsDefinitionService and other registry consumers unaffected.
• DI registration in AddJsEval switched from lambda-factory closures to type-based registration (AddScoped<JsEngine>(), TryAddScoped<IJsModuleBuilder, JsModuleBuilder>()). Wolverine 6's strict codegen rejects opaque ImplementationFactory closures regardless of how clean the underlying ctor is — type-based registration lets the static analyzer walk the ctor like any other service.

Migration (only for direct new JsEngine(...) callers)

// Before (4.0):
new JsEngine(serviceProvider, moduleRegistry, options, logger);

// After (4.1):
new JsEngine(moduleRegistry, new JsModuleBuilder(serviceProvider, moduleRegistry), options, logger);

Wolverine 6 allowlist

After bumping, all per-consumer AlwaysUseServiceLocationFor<T>() entries for JsEngine-dependent services can be deleted from Program.cs. The only remaining entry needed is for IJsModuleBuilder — modules can declare arbitrary host-resolved ctor params, so the locator pattern is unavoidable inside that single service:

opts.CodeGeneration.AlwaysUseServiceLocationFor<IJsModuleBuilder>();

Hosts only ever inject JsEngine, never IJsModuleBuilder, so the boundary stays clean.