deferred-di-reflect-metadata-optimization

Delete the eager `import 'reflect-metadata';` from the client entry only when the DI composition root loads the container behind a dynamic import and imports the shim itself. Then pin the removal with a unit test asserting the entry source contains neither import.

Removing the eager reflect-metadata import takes roughly 16 KB gzip off the critical render path. The measured mobile Lighthouse lift is approximately +0.03 on the performance category, but always confirm with a bundle report since the number depends on what else the entry pulls in.

It is unsafe when the entry file or anything in its static import closure declares or instantiates a decorated class such as one marked with @injectable(). In that case the eager import is load-bearing and removing it causes a runtime failure on first resolution.

Resolution fails because a decorated class was reachable through the entry's static import closure, so the metadata shim was still needed eagerly. Walk the full static closure before removal; the error only surfaces at runtime, not at build time.

No. Next.js app shapes and Storybook-first component libraries have no tsyringe DI container, so the skill is inapplicable. It targets React SPAs with a deferred composition root such as a dependency-injection-config module loaded via dynamic import.