[Meta] Expose Drupal Components outside of Drupal

Plus a 1000000000000000 for this!

Oh yes, share the goods.

One task, perhaps the most essential and most troublesome, is missing in the task list:

The subpath split needs to be automated as a post-commit hook or re-executed on a daily basis.

das

This is exactly what I was hoping we'd move to with the Components namespace. +1 google. :-)

I'm a symfony 2 developer and i'm interested in the component that lets you compose a form in the user interface (does that have a name?). Using the same packaging strategy as symfony 2 allows the components to get more traction and thus more cooperation. +1

@flip01 you are probably thinking of the webform module http://drupal.org/project/webform : this is a contributed module, not part of core, so not affected by this discussion.

Pulling some issues together for better visibility. Some of there are potentially duplicates with each other...

The issue summary says this:

1. Introducing a composer.json for each component
2. Creating a subpath split in a new repository for each component
3. The subpath split needs to be automated as a post-commit hook or re-executed on a daily basis.
4. Post the components on https://packagist.org

But that's not what needs to happen.

Each component must become its own d.o project.

For instance, with Drupal\Component\Plugin, we'd need the following:

1. Figure out who will maintain this new project.
2. Perform the subpath split once on core/lib/Drupal/Component/Plugin.
3. Move all the resulting files into a src/ directory.
4. Figure out how to move tests/lib/Drupal/Tests/Component/Plugin under tests/ without losing history.
5. Add README.
6. Add documentation.
7. Add composer.json.
8. Push to awaiting d.o project, named something like component_plugin.
9. Add packagist.org entry.
10. Remove Drupal\Component\Plugin namespace from core.
11. Add dependency within Drupal.
12. Have api.drupal.org spider the new project.

@Mile23, please open a 9.x issue for that.

Can't just promote this one to 9.x?

@Mile23
The way how you also could do it, is to provide subtree splits ... as well as add composer.json to all components in core directly.

Tests are a problem here, but I don't see how that negates the current IS.

Eclipse

Well, in that case we could move around the tests and adapt our phpunit configuration to point to those specific tests.
I don't see a big problem with doing that, beside that its maybe out of scope of 8.0

Yeah, I'm not sure delivering tests with the component is of greater value than exposing the component. I'd much rather make our stuff available w/o tests than delay the whole thing till we can reorganize the code.

Eclipse

The only advantage I see is that new people coming to the project willing to work on a component will have a easier time finding those tests.

I absolutely agree.

Moving the tests around is a nice-to-have IMO. One wouldn't be able to send in patches or PRs against one of the forked components anyway; you'd need to work against Drupal itself. For now let's just add a bunch of composer.json files.

See us over in #2337283: Add a composer.json file to every component

Clarifying the original issue with some steps to take.

Moving to 8.1.x as per #2600718-17: Add composer.json to \Drupal\Component\Bridge component.. Also tagging for framework manager review. Thanks!

Come to think of it, we probably also need to have Dries sign off on this, since it's the philosophy and structure of the project and blah blah etc. Not assigning to him just yet though until the framework managers can give their review.

So I understand that this isn't in the list of things we can commit in 8.0.x, but I don't see why we couldn't alter that for composer.json files in Components. Do we have a documented reason why that sort of change would not be acceptable? I'll admit, from all the conversations I've had on this topic, I'd always assumed that composer.json files during the 8.0.x release cycle were completely ok. I could also understand requiring them in 8.1.x first with backports, but I'd hate to see this entire meta's scope postponed to the next Drupal version. (looking for clarity here, I realize we probably need Dries to point the way on this)

On a similar note, I have been encouraged on multiple occasions to just make Plugins & company available via composer on github repos. I have resisted thus far, because I feel like doing that would slow down the process of exposing our own components, which I think is of great value. If we could:

1. Get Dries perspective on this
2. Assuming that's a general green light, get d.o perspective on this

I think those two things would go a LONG way toward setting reasonable expectations around this, and we could discuss what other related solutions we might want to consider in the mean time.

Eclipse

Come to think of it, we probably also need to have Dries sign off on this, since it's the philosophy and structure of the project and blah blah etc.

This is odd, because we already expose multple of them, and well, those didn't needed signoff dries:

• #2497243: Replace Symfony container with a Drupal one, stored in cache
• #2474903: Add composer.json to \Drupal\Component\Gettext\ component.
• #2211633: Provide a composer.json file for Drupal\Component\Plugin
• #1973618: DIC: Lazy instantiation of service dependencies (ProxyManager for "proxy services")
• #2176065: Introduce a composer.json for Drupal\Component\Utility

In general this is not a decision in my point of view ...
If there is a reason against exposing this to the wider PHP community, we have an insurmountable philosophical disagreement.

What I also don't understand, is how this changes
anything on the structure of the project. We don't split up the repository.

So there are a few steps here...

One is to add some files to the repo. #2337283: Add a composer.json file to every component

Another is to split the repo using subtree split, and maintain that, and maintain listings on packagist. #2513388: Create (and maintain) a subtree split of each Drupal Component

Is it possible that we can do the former in 8.0.x, while we have work being done by newbies who are motivated, and postpone the latter, with the possibility that maybe we can revisit it when the former is done?

These changes are not bug fixes and therefore there's no need to do this in 8.0.x as @xjm said in #27. 8.0.x is for bug fixes to stable code.

Re #28 Dries already approved this in #2176065-33: Introduce a composer.json for Drupal\Component\Utility

Wondering if there's any possibility for this during 8.1.x instead of 8.2.x.

This needs to be done in the development minor, which is 8.3.x now. Thanks!

Well one more important part is to actually expose them on packagist, which the owner of the namespace have to do.

Has any progress been made on this? I would like to use some of Drupal's components in a non-Drupal project. :/

#2352091-45: Create (and maintain) a subtree split of Drupal core

Looks like we have liftoff. :-)

New child issue: #2873101: Component version constraints are out-dated

IMHO we could have issues for the following bits:

• expose the components in core/lib/Drupal/Core/*. It is tricky to get the dependencies right
• Expose the individual modules in core/modules/*. It is tricky to get the dependencies right
• Expose the individual themes in core/themes/*

New child issue that cleans up the composer dependencies of the components: #2867960: Merge Component composer.json files to account for them during build

Actually *requiring* the components (instead of just replacing them, like we do now in core/composer.json) would mean having two copies of the code, one under core/lib and one under vendor/.

Also this one, which is pretty big in scope: #2385395: Make Drupal core folder agnostic and allow it to be placed in vendor/drupal/core

Everything on this meta is done, except for the licensing issue, and based on that issue, its not even clear that it is something that needs to be/should be done.

Im going to mark this RTBC and somebody else can close it.

Once #2867960: Merge Component composer.json files to account for them during build is fixed, we'll have made all the components consumable by other projects.

#2867960: Merge Component composer.json files to account for them during build is fixed, with #2876669: Fix dependency version requirement declarations in components ready to take up the loose ends.

Resetting RTBC.

@Mile23 has there been any discussion about where the tests for each component should live? I guess we can't move them into each component whilst each component folder doesn't have a src folder too. That would be quite a bit re-organisation but it would be nice.

I guess we could mark this fixed? It would be nice if someone goes through the issue summary and uses the strikethrough to mark what's done.

I struck out the stuff in the issue summary that I was aware of being done.

I did find a couple issues that we'll need to follow up on:

Add README, LICENSE, whatever else

The LICENSE.txt file for both the Serialization and the Transliteration components are blank files.

Ignore tests (for now).

Maybe a follow up for putting the tests for components with the components.

Allow licensing text files in our coding standard.

I dont know if this is done or not. But we're not codesniffing txt files so....

Create Drupal project issue components for each component released in this way.

Not sure what this means exactly... have a 'project' on drupal.org so we have component specific issues?

Anyhow, these are on packagist.org, and drupalci happily depends on core-annotation and core-plugin. Thanks for the code Drupal!

Create Drupal project issue components for each component released in this way.

Basically I think this is saying make each component its own d.o project. I guess we're deciding not to do that by figuring out how to move the tests to the components.

@Mile23 has there been any discussion about where the tests for each component should live? I guess we can't move them into each component whilst each component folder doesn't have a src folder too.

Since we're merging the components' composer.json now, we can specify autoload and autoload-dev per component, and take the Drupal\Component namespace out of core/composer.json's autoload section. Then we can put the tests in the component directory. That would mean a composer dumpautoload per live site, so it's a teensy bit disruptive, but not really since you're going to composer install the update anyway. It's also not terribly tricky.

Added child issue. I guess this meta's still active. :-)

#2943842: Allow component namespaces to be autoloaded independently

Added child #2943856: [meta] Reorganize Components so they are testable in isolation so I could take notes on a few things. Postponed on #2943842: Allow component namespaces to be autoloaded independently

Added the other followup: #2943860: Add a LICENSE.txt to Serialization and Transliteration components

The components all need READMEs that actually explain how to use them, otherwise there is no point in making them usable as standalone packages.

Currently, all they say is a cheery "Thanks for using this Drupal component."

Great, but HOW do I use it?

We need a way to make the composer.json files maintainable: #3272110: Drupal 9 and 10's Drupal\Component composer.json files are totally out of date

They are broken for D9+ but no one has noticed...

Is this a feature in search of a use-case in 2022? There is a nonzero support burden. Would anyone actually use these things?

I'm using it in https://packagist.org/packages/parisek/twig-attribute eg. in WordPress theming :)

@cilefen I said similar things in Slack (and actually my original issue was significantly more, er, scathing).

Apparently some people use them. I drilled in a bit on package usage. A whole four non-core components depend on the Render component, for example. @larowlan also mentioned using them to add utility functionality to D7 sites. 🤷‍♀️

Is it worth the maintenance burden for that? Meh. For me, I'm inclined to say no unless the process for updating them can be wholly automated, and I hope that the people who want these packages to exist could take the time to do the automating.

DrupalCI uses drupal/core-annotation.

Hey, guess why I'm here... I found myself needing to use Attribute and some render components for twig stuff outside Drupal today. 🙃 Glad Parisek's project was there because it pretty much exactly what I was looking for but would have been nice to have been exposed by core.

I also use core-utility in a Laravel app that need align some processing with the main Drupal site.

Also, I don't currently use it, but I've used NestedArray and Timer from core-utility for misc one of scripts and testing because I've not found a lot similarly useful libraries.

_Also_ I've been arguing since we started building /lib that doing this provides its own value. Pushing things down to components that can be split forces us to unravel complexity and write better less smelly code. Still see that as true.

+1 on less smelly.