FriendsOfSymfony / FOSRestBundle

This Bundle provides various tools to rapidly develop RESTful API's with Symfony
http://symfony.com/doc/master/bundles/FOSRestBundle/index.html
MIT License
2.79k stars 707 forks source link

[RFC] Remove framework-bundle dependency #2333

Open Th3Mouk opened 2 years ago

Th3Mouk commented 2 years ago

While working on #2330, and the question of symfony/routing upstream dependency. I figured out symfony/framework-bundle is only used for https://github.com/FriendsOfSymfony/FOSRestBundle/blob/3.x/Controller/AbstractFOSRestController.php#L20. What about move the framework-bundle dependency to the require-dev section ? It will allow to remove cache finder filesystem dependencies in downstream projects.

Symfony handle this kind of behavior with a constructor check to inform the end user of a missing dependency to use the abstract controller. Most of the logic is already in a trait and probably a good documentation on this is enough to explain controllers helpers to users. How to work without anything, the trait, the abstract controller.

mbabker commented 2 years ago

I don't know if it really matters here to have the FrameworkBundle as a direct dependency. Can you realistically deploy a Symfony application without it?

Th3Mouk commented 2 years ago

In theory yes, framework bundle is kind of bootstrap, and you can create your own framework with components and without the "glue" of framework bundle. In practice I created severals frameworks but never with FOSRestBundle in dependency. Now I don't think too much persons have installed the bundle without this dependency. The aims is simply to reduce severals upstream dependencies to ease maintenance of the bundle and downstream projects.

mbabker commented 2 years ago

Personally, I'd say the added overhead isn't worth the hassle. For the overwhelming majority of use cases, FrameworkBundle is going to be installed, so moving it out of the required dependencies then adding a runtime check when the AbstractFOSRestController.php file is loaded isn't really going to bring about many benefits to either the maintenance of this bundle or consumers of it (maybe it's because I don't have the same experience of building my own tooling and not using the core FrameworkBundle, but I'd say that not having that bundle is an extremely niche use case).

You might get more benefit out of moving symfony/security-core out of the hard required list as the Security component is only used in the optional DisableCSRFExtension form extension. But again, from a practical perspective, the odds of it not being pulled into a Symfony application are pretty low.

Th3Mouk commented 2 years ago

I understand this point of view