Container Implementation - Fork league/container or develop our own

[jamisonbryant]

Description

The Main Idea

We should consider either forking the league/container library or developing our own container implementation directly within the CakePHP Core. This would eliminate our dependency on upstream fixes and give the CakePHP Core team complete control over this critical component of the framework's architecture.

Potential Roadblocks

• Philosophical shift: Moving away from leveraging community packages toward maintaining more functionality in-house
• Userland impact: Potential pushback from the community about not supporting/using established packages
• Transitioncomplexity: Managing compatibility between existing service containers and new ones built the Cake way
• Core bloat: Adding another component to maintain within the Core could increase complexity
• License considerations: Need to ensure proper attribution if forking or using any code from the package
• Reinventing the wheel is a double-edged sword

User Feedback/Frustration

• Cake's current container implementation has a big learning curve, and is much less user-friendly than most Cake features
• Improvements to our container implementation requires upstream fixes to be merged, and thus creates a potential for blockers
• Relying heavily on another library's error messages can lead to confusion, e.g. 'what the heck does "the container lied" mean?'

Potential Next Steps

1. Document specific limitations and pain points with the current container implementation
2. Survey other PHP frameworks for container implementation approaches and lessons learned
3. Create a prototype implementation within a development branch
4. Maybe discuss with league/container maintainers about potentially taking over as maintainers rather than forking
5. Establish clear criteria for backward compatibility if implementing our own solution

CakePHP Version

6