Skip to content
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

Open
schlessera opened this issue Oct 10, 2016 · 5 comments
Open

Get rid of external packages #4

schlessera opened this issue Oct 10, 2016 · 5 comments

Comments

@schlessera
Copy link
Member

Get rid of the direct coupling to doctrine/collections and symfony/finder, as the risk of running into version conflicts when using for public plugins is too high.

@tedmasterweb
Copy link

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?

@schlessera
Copy link
Member Author

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.
This can produce situations where multiple plugins rely on the same library, but in different, conflicting versions.
Due to the way autoloading and WordPress plugin loading work, this will make the library available in the version that is being triggered the soonest, and all other plugins risk breaking because of this.
This problem can only be solved if you use Composer at the site-level, for the entire stack, and have all dependencies for all plugins be resolved in an atomic way.

@tedmasterweb
Copy link

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.

@schlessera
Copy link
Member Author

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.

@tedsecretsource
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants