[damyanpetev]

The full IgniteUI.Blazor package is moving onto this package's runtime: AddIgniteUIBlazor registers it, and the full package keeps its own runtime state alongside. What it needs from this package is the JS runtime.

Apps preload modules by listing them in AddIgniteUIBlazor. The runtime calls each listed module's static Register(IIgniteUIBlazor) as it is constructed, and that call is the only thing a full-package module receives. To request its client code it needs an IJSRuntime, which the empty IIgniteUIBlazor did not carry. So its preloads had to wait for the first full-package component to bring one, or were never sent on pages without one.

IIgniteUIBlazor.JsRuntime returns the runtime's IJSRuntime. It is [EditorBrowsable(Never)]: infrastructure for the full package, not app API. Nothing else on the runtime becomes public.

Also, while the full package deprecates its own IgniteUIBlazor class, that class registered in place of AddIgniteUIBlazor no longer makes the components throw: it gets a runtime of its own. It is recognized by type and assembly name, since that package depends on this one. Any other IIgniteUIBlazor implementation is still rejected. This bridge goes away with that class.

Verification

• Unit suite on net8.0, net9.0 and net10.0: all pass, no new warnings. The bridge is tested with a type of the full package's name, emitted at test time into an assembly of its name; that test fails when the name doesn't match. A second test checks that another implementation is still rejected.
• Against the full package built on this branch (dev-tools #4043), rendered through HtmlRenderer with a stub IJSRuntime:
  • With AddIgniteUIBlazor, a preloaded full-package module is requested when the runtime is created, also on a page with only a Lite component.
  • With the full package's deprecated IgniteUIBlazor as the registered service, both a full-package chart and a Lite button render and request their modules.

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

The focused interface addition, compatibility bridge, and regression tests have no identified blocking issues.

No open issues 🎉

What changed in this PR

Exposes the JavaScript runtime through IIgniteUIBlazor so the full package can preload modules using the shared runtime infrastructure.

Changes:

• Adds an infrastructure-only JsRuntime accessor, hidden from IntelliSense.
• Adds a temporary compatibility bridge for the full package’s deprecated runtime while continuing to reject other implementations.
• Adds tests for runtime access, compatibility module loading, and unsupported registrations.

File	Description
tests/​IgniteUI.Blazor.Tests/​ServiceRegistrationTests.cs	Tests the accessor and compatibility registration behavior.
src/​componentsBase/​IIgniteUIBlazorRuntime.cs	Adopts recognized legacy runtime instances through a weakly cached bridge.
src/​componentsBase/​IgbComponentBase.cs	Exposes IJSRuntime on the public service interface.

_{Review effort: Balanced}