Closed
Conversation
Introduces a new system for defining and registering components,
replacing the centralized `ComponentRegistry.ts`.
Key changes:
- **ComponentManifest:** New `ComponentManifest<TData>` interface
(`src/core/components/types.ts`) defines the structure for
component definitions, including metadata, Zod schema for data,
default data, rendering/physics contributions, and lifecycle hooks.
- **Auto-Discovery:** Component manifests are now defined in individual
files within `src/core/components/definitions/`. These are
auto-discovered by `src/core/lib/ecs/dynamicComponentRegistry.ts`
using Vite's `import.meta.glob`. This dynamically builds the
`AUTO_COMPONENT_REGISTRY` and `AutoKnownComponentTypes`.
- **Core Components Refactored:** `Transform`, `MeshRenderer`, `RigidBody`,
`MeshCollider`, and `Camera` have been migrated to the new
manifest structure.
- **Updated Component Usage:**
- `ComponentManager.ts` now uses `ComponentManifest` for data
validation (via Zod schemas) and lifecycle hooks (`onAdd`, `onRemove`).
- Editor UI (`AddComponentMenu.tsx`, inspector adapters) updated to
use the new dynamic registry.
- `AUTO_COMPONENT_PACKS` is now defined in `dynamicComponentRegistry.ts`.
- **Documentation:** New guide `docs/development/adding-new-components.md`
explains the new process.
- **Tests:** Unit tests (Vitest) added for `dynamicComponentRegistry.ts`
and `ComponentManager.ts` to cover discovery, validation, and
lifecycle logic.
- **Cleanup:** The old `COMPONENT_REGISTRY` and related helpers in
`src/core/lib/ecs/ComponentRegistry.ts` have been removed.
`IComponentPack` type consolidated.
**Note:** `src/core/lib/ecs/IComponent.ts` and its `KnownComponentTypes`
enum are still widely used throughout the codebase. While the new system
uses string IDs that are compatible, a full refactor of these usages
was out of scope for this change and can be addressed separately.
Adds more specific tests for the core components (`Transform`,
`MeshRenderer`, `RigidBody`, `MeshCollider`, `Camera`) that were
recently refactored to the new ComponentManifest system.
- **ComponentManager & Actual Manifests:**
- `ComponentManager.spec.ts` now includes tests that use the
actual manifests of these core components. This verifies
`addComponent` and `updateComponent` logic against their
real schemas, default data, and `onAdd` hooks.
- **Contribution Functions:**
- New tests in `CoreContributions.spec.ts` directly validate
the output of `getRenderingContributions` (for MeshRenderer, Camera)
and `getPhysicsContributions` (for RigidBody, MeshCollider)
from their respective manifests using sample data.
- **Transform Bitecs Interaction:**
- Added tests to `ComponentManager.spec.ts` that specifically
verify the direct modification of the `bitecs` `Transform`
store (position, rotation, scale arrays) when `ComponentManager`
adds or updates `Transform` components. This ensures the
link between the high-level ComponentManager operations and
the low-level `bitecs` data layer for `Transform` is correct.
- Also tests the behavior for attempting to remove the non-removable
`Transform` component.
jonit-dev
added a commit
that referenced
this pull request
Oct 1, 2025
…bility - Made MaterialRegistry constructor public (was private) - Kept getInstance() method with @deprecated annotation - Registered MaterialRegistry in global DI container - MaterialRegistry now available via: container.resolve('MaterialRegistry') - Old singleton pattern still works during migration phase - Added MaterialRegistry to core public API exports - Fixed linting errors (require import, restricted paths) This is Phase 1 of singleton elimination - enables gradual migration to DI pattern without breaking existing code. Related: SCALABILITY-IMPROVEMENTS.md #1 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
jonit-dev
added a commit
that referenced
this pull request
Oct 1, 2025
- Added MaterialRegistry as constructor parameter - Falls back to getInstance() for backward compatibility - MaterialSystem now supports both DI and legacy singleton pattern - All tests passing (488 passed, 5 skipped) Related: SCALABILITY-IMPROVEMENTS.md #1 - Phase 1 singleton elimination 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.