-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get rid of external packages #4
Comments
Having seen similar issues in other plugin frameworks that depend on Symfony, I'm wondering if you could give a concrete example of what the potential problem is. Would pegging the Symfony version in composer.json to a specific version solve the problem? |
The specific issue when building WordPress plugins is that Composer is not run for the store as a whole (resolving conflicts or throwing errors when there are conflicts), but rather for every plugin independently. Because of this, Composer cannot detect conflicts across plugins. |
Thanks for the clarification. We're in a similar situation. I'm going to have to do the same thing or run the risk of breaking someone else's plugin (or my own not working). I am not looking forward to it, at all, because I used the Herbert framework and that depends heavily on Illuminate / Symfony. I know this is not a unique problem. What's your plan for fixing? Refactoring? Forking Symfony and maintain yourself? Thanks again. |
In my case, the external dependencies are already very targeted and don't encompass the entire Symfony framework, but rather small subsets of functionality of specific components. I plan on doing my own, reduced versions of these components, as I'd like for the Bright Nucleus framework/components to only rely on Bright Nucleus dependencies. These are certainly less popular than Symfony ( 😅 ) and under my direct control. |
Thanks a lot for the clarification. As a plugin developer, it sure would be nice to have some WordPress-sanctioned libraries that facilitate plugin development beyond what's available in the Plugin and Settings APIs, which are a good start, I suppose, but seem to fall far short of what most people need. Anyway, I digress. Thanks again and feel free to close this case. |
Get rid of the direct coupling to
doctrine/collections
andsymfony/finder
, as the risk of running into version conflicts when using for public plugins is too high.The text was updated successfully, but these errors were encountered: