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

[LordSimal]

See https://github.com/cakephp/cakephp/pull/18090

[jamisonbryant]

@LordSimal can you provide a few words as to why the above mentioned implementation was closed? It looks like you had made/were making good progress.

[LordSimal]

Because I got no feedback about the questions I asked like https://github.com/cakephp/cakephp/pull/18090#discussion_r1904415122

and the fact, that a new major has been released of the base repo which I havent ported over yet

[dereuromark]

Well, every week that passes and https://github.com/cakephp/cakephp/pull/18252 stil goes nowhere and the related PR despite my ping is also not going anyway, I feel more convinced we should do it. You just cannot trust too many such small entities upstream.

[dereuromark]

Are we closing this for now ?

[markstory]

I'm open to vendoring the league container into our code. We need to keep attribution and comply with their license (MIT which is nice and easy). That gives us a path to fix bugs more efficiently, and start adding more ergonomic APIs if we have some in mind. I think we should maintain PSR compatibility though. It gives us and the community flexibility in the future.

[github-actions[bot]]

This issue is stale because it has been open for 120 days with no activity. Remove the stale label or comment or this will be closed in 15 days

[LordSimal]

with e.g. https://github.com/cakephp/cakephp/pull/18911#event-19817704023 coming next minor I don't believe we will follow up with porting over the container implementation.