Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
The following list prooves that noone is aware of http://cgit.drupalcode.org/drupal/tree/core/lib/Drupal/Component/README.txt
- \Drupal\Component\Annotation\Plugin\Discovery\AnnotatedClassDiscovery relies on Doctrine\Common\Annotations\SimpleAnnotationReader
- \Drupal\Component\Bridge\ZfExtensionManagerSfContainer relies on symfony and Zend, obviously
- \Drupal\Component\Discovery\YamlDiscovery does not actually work
- \Drupal\Component\Serialization\Yaml relies on Symfony\compotent\yaml
Current text:
Drupal Components are independent libraries that do not depend on the rest of
Drupal in order to function. Components MAY depend on other Components, but
that is discouraged. Components MAY NOT depend on any code that is not part of
PHP itself or another Drupal Component.
Each Component should be in its own namespace, and should be as self-contained
as possible. It should be possible to split a Component off to its own
repository and use as a stand-alone library, independently of Drupal.
Proposed resolution
Adapt README.txt to reality and allow us to share code with other folks!
Remaining tasks
User interface changes
API changes
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | components-2303777-13.patch | 1.06 KB | jhedstrom |
| #13 | interdiff.txt | 702 bytes | jhedstrom |
Comments
Comment #1
dawehneradd current text
Comment #2
Crell commentedSince sun claimed in the previous issue that there was ambiguity, I want to just call out this line:
"Components MAY NOT depend on any code that is not part of PHP itself or another Drupal Component."
There is absolutely no ambiguity in that line. People have just been ignoring it.
Comment #3
sunThe quoted sentence defeats the purpose of modern, decoupled OO packages/libraries. Like any other PHP package,
Drupal\Componentcomponents should be able to depend on other PHP packages.But anyway, let's shoot for a crystal clear clarification here. → See attached patch.
In case we disagree, then I can only assume the original intended policy must have been this:
Drupal\Component.Drupal\Core.Such a (weird) stance would cut down
Drupal\Componentto just a handful of [semi-]original art; e.g.,Transliteration,Plugin,Gettext,PhpStorage.I couldn't disagree more with that idea, because it attempts to enforce artificial limitations for components that would not exist otherwise.
Comment #4
sunAdjusted the alternative wording to be more clear.
Comment #5
dawehner\Drupal\Components is the place for me where the Drupal community developers code which can also be used by other folks.
If there is an invidium (sdboyer) who decides to write his own library and include it into core via composer, this is fine as well.
+1 for the visual distinction.
+1 for mentioning enviroment aspects! I think it is fine to drop PHP from here, because this is really kinda obvious. I tried to have a look whether symfony do have a definition, but they don't seem to have one, yet.
Comment #6
ParisLiakos commented+1
I can understand why we dont want a component to depend on Drupal stuff, but i do not see why we cant depend on other php libraries
Comment #7
tstoecklerYes, let's do this.
Comment #8
catchWhat's a Drupal environment aspect?
Comment #9
Crell commentedI wrote the original text as part of the initial namespace patch.
The intent was 2-fold:
1) Encourage the development of Drupal-decoupled (not just loosely coupled but entirely decoupled) components with the very explicit intent of them being offerable via Composer independently of Drupal.
2) Encourage the generally good practice of fully decoupled low-level components. Symfony Components consist of a mix of decoupled (eg, YAML) and loosely coupled (eg, HttpKernel) components. Generally speaking the lower-level the component the more decoupled it should be. We want to avoid "loosely coupled but deep dependency tree" systems in favor of a broad-and-shallow dependency tree.
The (admittedly rather strict) description in the current text therefore does not "defeat[] the purpose of modern, decoupled OO packages/libraries." It encourages fully separated but reusable components.
So the question is, if we soften the standard, what do we lose? I don't want to see a bunch of "components" that still have 8 layers of dependencies on each other or various other packages so that every one is a hidden megabyte worth of code. (An extreme example, yes, but given Drupal's history I think it's a not unreasonable fear.)
Comment #10
sunIn case there is community consensus on that stance, then in my mind, the only remotely sensible model would be:
Totally decoupled components: External libraries pulled in via Composer.
Totally decoupled components are not Drupal code. Why would we even attempt to maintain them within Drupal to begin with? Just to have "Drupal" in their name? No, marketing is not an argument. We've learned how to integrate and contribute upstream in the meantime.
→ For example, Plugin is removed and added back to Drupal via Composer.
→ Ditto for e.g. Transliteration. (Being one of the original Transliteration module maintainers, I still care for its future.)
Decoupled components that don't rely on Drupal but happen to "share" its dependencies:
Drupal\Component→ The vast majority that doesn't fit in (1) stays where it is. They'll have
composer.jsonfiles, but only for potential future subtree splits.Bridge components + Drupal-specific core components:
Drupal\Core→ As-is. Any kind of dependencies, inside and outside of Drupal.
Comment #11
catch#10 seems like a reasonable split, either way the wording needs fixing to reflect what's actually supposed to be in Component, but still think #8 needs fixing.
Comment #12
dawehnerWell, I think having Drupal as vendor would still be nice, given that the Drupal community worked on it. I would though agree that having
them separate would help us to ensure that we use proper semv.
@sun
This blocks us from sharing useful code on top of other NON-Drupal components, for example #2296205: Create a \Drupal\Component\Routing\ namespace and move Drupal-independent routing classes into it. I think it would be great to specify that in case your code just depends
on other external components, it is fine to put it somewhere where a potential subtree can happen.
Comment #13
jhedstromThis patch simply removes that second part of the sentence. I think
is clear enough?
Comment #14
Crell commentedI still do not support this, but the patch more accurately describes what we're doing in practice despite the potential downsides.
Comment #15
dawehnerA different approach could be also to add composer.json files to the Drupal/Core directories and add some suggested dependencies.
Comment #16
catchHonestly describing what we actually do ++.
Can always revise the wording if we start handling things differently.
Committed/pushed to 8.0.x, thanks!
Comment #18
dawehnerWhen each
\Drupal\Componentshave acomposer.jsonwe do have kind of explicit documentation on what other external packages they rely/build upon on.Comment #19
Crell commenteddawehner: There's another issue somewhere to add composer.json files to everything. One or two already have them. Please add more. :-)
Comment #20
kim.pepperLooks like @dawehner has created that issue already #2337283: Add a composer.json file to every component
Comment #21
mile23