Introduce a composer.json for Drupal\Component\Utility

+++ b/core/lib/Drupal/Component/Utility/composer.json
@@ -0,0 +1,23 @@
+  "name": "drupal/utilty",

typo :-P

1. +++ b/core/lib/Drupal/Component/Utility/composer.json
   @@ -0,0 +1,13 @@
   +  "require": {
   +    "php": ">=5.4.0"
   +  },
   

   Let's go with 5.3.10 for now.

2. +++ b/core/lib/Drupal/Component/Utility/composer.json
   @@ -0,0 +1,13 @@
   +  "description": "Common utility classes for Drupal components.",
   

   Maybe some examples would be helpful (String/XSS)

3. +++ b/core/lib/Drupal/Component/Utility/composer.json
   @@ -0,0 +1,13 @@
   +  "homepage": "http://www.drupal.org",
   

   Should we link to https://www.drupal.org/project/drupal instead?

+++ b/core/lib/Drupal/Component/Utility/composer.json
@@ -0,0 +1,13 @@
+  "name": "drupal/utility",

I wonder whether we should prefix the drupal core components somehow. (drupal/core-utility). Just wondering.

Let's go with that as a first step.

We should consider to create an issue somewhere to do an automatic subtree cron based splitting

+++ b/core/lib/Drupal/Component/Utility/composer.json
@@ -0,0 +1,13 @@
+  "autoload": {
+      "psr-0": { "Drupal\\Component\\Utility\\": "" }
+  }

Is it is very likely that we'll copy/paste this first file as a template later on, can we (1) fix the indentation and (2) turn the inner namespace hashmap onto a separate line?

In short:

  "autoload": {
    "psr-0": {
      "Drupal\\Component\\Utility\\": ""
    }
  }

This 4 spaces clearly from the outside world which pretty much all uses 4 spaces in the composer.json files. Maybe we should discuss that somewhere.

I've seen composer.json files in the wild using 2 spaces, 4 spaces, or even tabs.

I don't think there is a coding standard for composer.json files. → As long as it's valid JSON, everything works.

I don't really care which form we're going to use, but I think there is one crystal clear rule that we can all agree to:

Within the scope of a single file, the style should be consistent.

The autoload:psr-0 lines are the only lines that diverge from the rest of the file. There are multiple ways to fix this, just choose one. I'd personally prefer to stick to 2 spaces, but again, only consistency matters. :)

Thanks! :-)

Now, personally, I'd like to perform the following change for maximum accuracy + architectural sanity, but I'm not sure whether we're able to do it right now, because AFAIK there is at least one offender (Settings):

-  "description": "Utility classes for Drupal components including string, xss, array, image and other commonly needed manipulations.",
+  "description": "Static utility classes for Drupal components including string, xss, array, image and other commonly needed manipulations.",

In other words: Any class that is not a static utility function class (mainly wrapping PHP core code) has absolutely no place in \Drupal\Component\Utility. It concerns me that this is not a hard requirement for \Utility.

That said, I'd also drop the "Drupal components including" part. → By exposing them to the public, they are no longer for "Drupal components" only. :P

-  "description": "Utility classes for Drupal components including string, xss, array, image and other commonly needed manipulations.",
+  "description": "Static utility classes for string, xss, array, image, and other commonly needed manipulations.",

"Mostly static" is an excellent idea and compromise! :-)

The license property doesn't seem to match the documented ones. From the doc, we should be using GPL-2.0+.

https://www.drupal.org/ redirects to https://drupal.org/ so wouldn't it be more correct to use: https://drupal.org/project/drupal ?

Looks like a good start.

I have no idea what this is for, let's get an updated issue summary.

When I asked Eclipse what it was for, he said it was to allow Component to be split off and that sounds like a strategic question, so also assigning to Dries. This might not actually need to happen, but I can't tell because there's no issue summary. :)

Adding parent issue for context.

@webchick
So yeah it is not about splitting up the code itself, it is about supporting people which want to reuse the component in NON-drupal variants.
Theoretically this is already possible, though it is kind of a mess without the composer.json file.

+++ b/core/lib/Drupal/Component/Utility/composer.json
@@ -0,0 +1,15 @@
+  "description": "Mostly static utility classes for string, xss, array, image, and other commonly needed manipulations.",

"xss" should be "XSS", I think.

I'm not sure why this needs approval from Dries — for now, the intention is just to perform periodical git-subtree splits (exports) from git.drupal.org/project/drupal into standalone repos per component. The "master"/originating code stays in core.

The composer.json only needs to be added to core, because the subtree-split should be a 1:1 copy of the originating code. A composer.json file is required to use a standalone component with Composer.

In essence, we want to do the exact same thing as Symfony: All Symfony components are maintained in a single project repository, and each of them is split/exported into a standalone repository. This allows other projects (like Drupal) to cherry-pick the components they want to use.

This looks like a good idea to me (but a low priority).

I'm fine with having read-only clones outside of core, but for now I want these components to be maintained in Drupal core itself.

Unassigning from Dries since he answered.

Committed a50ebdf and pushed to 8.x. Thanks!

I validated the the composer json by running composer validate core/lib/Drupal/Component/Utility/composer.json

I think we should have a change record to detail the purpose of this.

See #2210257: Bump \Drupal\Component\Utility's PHP requirement to 5.4.2.