Repository navigation
Replies: 1 comment 1 reply
|
Hello @chii0815 , I think keeping the Symfony bundle and Laravel service provider in separate repositories would make sense, especially if each integration needs its own setup, configuration, or framework-specific updates. For Symfony, a dedicated bundle that requires the main client library through Composer would fit well with the usual Symfony Flex workflow. Ideally, installing the bundle should handle the configuration and registration automatically, so users don't have to edit files manually. The Laravel integration could follow the same idea using its own service provider and package discovery. One thing worth considering is keeping the core API client framework-independent, with the Symfony and Laravel integrations maintained as separate packages. That would make the main library easier to maintain without tying its release cycle to either framework. We work with cloud infrastructure at AccuWeb.Cloud, so integrations that are straightforward to install and maintain are always useful from an operational perspective. Curious to see how you decide to structure this! Regards, |
Uh oh!
There was an error while loading. Please reload this page.
Should the symfony bundle and the laravel service provider be in their own repository?
For symfony there is symfony flex that would generate the config file and the bundle.php line while installing the "zammad-api-client-php-bundle" and therefor activating the bundle without manual editing lines. As far as I know that won't work with the symfony bridge at the moment.
The installworkflow normally is bundle requires library and symfony flex + composer will automatically install the library on requiring the bundle.
For Laravel I can assume it should be the same. But as I mainly use symfony this can differ.
All reactions