Require 'type' key in .info.yml files

Somehow, I thought that type was already in use, but seems I'm misguided on that, since neither http://drupal.org/node/542202 (module .info), http://drupal.org/node/1022020 (profile .info), nor http://drupal.org/node/171205 (theme .info) documents a type property.

This will involve a performance decrease that's potentially measurable, as every single .info file needs to be parsed first in order to determine what it is.

However, it can definitely considered to be a first step towards a unified "extensions" system, in which we unconditionally collect and record everything we have, and only later on demangle the data into extension "concepts". Right now, we're wasting quite a couple of resources for repetitively scanning the file system for each different concept we have.

A typical site will have so so much many more modules that on a module scan adding a theme or four wont matter. OTOH switching themes is really a rare operation compared to switching modules so making that heavier wont be a big deal.

Not to mention that all this hits the stat() cache which is very likely to contain all your Drupal site anyways :)

If it wasnt clear: I am strongly in favor because I never liked that hook in the theme issue.

Attached patch doesn't actually DO anything except add type=module, theme, etc to all core modules/themes/profiles. I'll attempt the hard part later!

In contrib-land, a semi-pattern of $name.$type.info has evolved, e.g. foo.skinr.info or bar.libraries.info.
How about comment.module.info or stark.theme.info?

Hmmm...I prefer the type=module approach but I'll defer to chx, catch, sun, et al on how to proceed.

What are the tangible benefits of #340723: Make modules and installation profiles only require .info.yml files that warrant both a DX hit and a performance hit?

#953336: Contributed modules are not able to test theme-related functionality is one. Are there others? Because you're asking every module, theme, and profile developer to have to write an extra line of code in their .info file (presumably with incredibly frustrating "WTF? Where the hell did my module go?!" results if that extra step is missed) in order to facilitate something we haven't had the need for in 11 years as a project.

See last para in #1. We're on the quest to a unified extensions system for a long time already, in which profiles and themes participate in the module hook system, modules may ship with themes, profiles ship with modules and themes, etc. This change is going to be a major milestone towards a generalization and simplification of the discovery and handling of extensions. Exact grants, responsibilities, and other business logic still can and has to be controlled by extension type, but the mere unification simplifies a lot and opens many doors.

Would like to go deeper than this and unify install_profile_info(), _system_rebuild_theme_data() and _system_rebuild_module_data(). Maybe in a follow up?

Totally. Already mentioned in #1. :)

Several other patches in the queue are heading for the same goal - but each touching separate parts of the spaghetti.

I'm not exactly sure how much we need to change in order to get this in?

Perhaps... it would be best to change "Add type key" into "Require type key", and replace the default type property value you added with an explicit condition?

// Skip this extension if its type does not match the type we are searching for.
if (!isset($info['type']) || $info['type'] != $type_we're_searching) {
  continue;
}

Likely needs an update. Let's find out!... #14: 1292284.patch queued for re-testing.

We have several modules in core right now that do not need a .module file..
eg hal..or serialization..not to mention the number of test modules..
I made the type required..and changed *i hope* all info.yml files

Yeah obviously i forgot all test themes and the fact that profiles are considered modules

this should be green...forgot a couple modules..it is weird how 3 missing modules can trigger so many fails:P

#23: drupal_info-type-key-1292284-23.patch queued for re-testing.

Paris tells me that this will help finally unblock #340723: Make modules and installation profiles only require .info.yml files. If he's right, then I'm +1 on it. :-)

lets see how many new modules/themes we have since then...i only spotted one.bot?

+++ b/core/modules/translation_entity/translation_entity.info.ymlundefined
@@ -1,4 +1,5 @@
diff --git a/core/modules/update/tests/aaa_update_test.tar.gz b/core/modules/update/tests/aaa_update_test.tar.gz

diff --git a/core/modules/update/tests/aaa_update_test.tar.gz b/core/modules/update/tests/aaa_update_test.tar.gz
index fc317ba..478f038 100644

index fc317ba..478f038 100644
--- a/core/modules/update/tests/aaa_update_test.tar.gz

--- a/core/modules/update/tests/aaa_update_test.tar.gz
+++ b/core/modules/update/tests/aaa_update_test.tar.gzundefined

+++ b/core/modules/update/tests/aaa_update_test.tar.gzundefined
+++ b/core/modules/update/tests/aaa_update_test.tar.gzundefined
@@ -1,3 +1,2 @@

@@ -1,3 +1,2 @@

Is the core/modules/update/tests/aaa_update_test.tar.gz touch suppose to be in here? Other than that, looks pretty good!

yes i had to extract it, put the type key in the info.yml end then recompress:)

Here it is without that change.

[EDIT] Ah, IGNORE THIS!!!

#27 is the RTBC patch.

Just for simplicity.

Committed 79ea2f3 and pushed to 8.x. Thanks!

Attached is a diff of the compressed file that's changing... so people can see what's actually changing...
Also core/modules/tracker/tests/modules/tracker_test_views/tracker_test_views.info.yml had been added in the meantime so added a type: module to it.

Re: performance concerns cited in #13, #11, #6 and #2 - I'm pretty sure that there won't be any impact as this patch does not result in any additional calls to drupal_parse_info_file().

Re: DX concerns cited in #11 adding an extra line into the info.yml is not really a burden considering module maintainers will already have to convert their .info into YAML anyway.

Attaching the promised diff of core/modules/update/tests/aaa_update_test.tar.gz

change notice: http://drupal.org/node/1990210
we can enhance it after #340723: Make modules and installation profiles only require .info.yml files

Awesome! Great work everyone!