Follow-up to: #1793074: Convert .info files to YAML



  • Enforce one extension per directory by using a static .info file name.

Proposed solution

  1. Rename all $ files into extension.yml


/core/modules/node/      » /core/modules/node/extension.yml
/core/modules/system/  » /core/modules/system/extension.yml


  • extension.yml is meant literally; i.e., "extension" is NOT to be replaced with the extension's name.
  • This inherently prevents two extensions to live in the same directory.
  • That's a critical aspect of D8's new architecture, but it is not enforced anywhere.
  • Therefore, an extension.yml (or perhaps even composer.yml?) file for each extension inherently enforces the architectural requirement that is not enforced in any way yet.
  • intuitive++


cweagans’s picture

As I stated in the composer issue, I am very much -1 to this.

Having multiple tabs open with the same filename sucks and I definitely don't want to add places in core where this happens.

Gábor Hojtsy’s picture

So I understand that this is proposed to be called an extension.yml because it applies to modules, themes, profiles, etc. The word core uses for the concept of all this in core is *component*. I understand why this might be confusing wrt Symfony components, but this is our existing terminology eg. in update module.

pounard’s picture

Having multiple tabs open with the same filename sucks and I definitely don't want to add places in core where this happens.

Actually I'm not sure this is a valid argument, it will easier all kind of scripting to do this, and could make the file system lookups much more efficient for finding modules.

JohnAlbin’s picture

The word "component" is also increasingly being used in front-end development. It refers to a "design component" that is a incapsulated, reusable bit of styling. And just to make it more confusing, design "components" is not a 100% ubiquitous term. They are also referred to as "modules", "blocks" and "elements". :-)

One thing they are not referred to as is "extensions". ;-)

Completely off-topic, I want "modules" renamed to "extensions". This proposed solution is in-line with that idea.

pounard’s picture

And recently bundle services registration are moving to a services.yml file. We could continue and move the module info into an extension.yml file, makes all of that being consistent.

sun’s picture

How many more good arguments do we need? Aside from the very strong (~bug) argument in the issue summary?

The one and only concern that was raised so far is #1, which generally is the uttermost edge-case that one can think of in terms of DX. (How often do you, really, have two .info.yml files open in your editor at the same time? And, for a better reason than copying from A to B?)

cweagans’s picture

That's kind of a major part of my workflow, actually. I jump back and forth a lot between features .info files and theme .info files (in this case, a subtheme of omega which makes heavy use of .info files for configuration storage). I wouldn't have brought it up if it wasn't going to be a problem.

Crell’s picture

Would this issue then imply we also rename $ to services.yml and $module.routing.yml to routing.yml?

webchick’s picture holds services.
module.routing.yml holds routes. holds info about the module/theme/whatever.

Why is the proposal not therefore info.yml? Then we're not inventing a new word for these things that we don't use anywhere else (if we wanted to use an existing word, that'd be "project," not "extension").

But I personally think is just fine, especially since we have those other naming conventions already.

nod_’s picture

Are themes included in the renaming of info files?

jibran’s picture

If #8 answer is yes then I think these names looks good.
services.yml holds services.
routing.yml holds routes.
info.yml holds info about the module/theme/whatever.
This also fulfills "Enforce one extension per directory" criteria.

sun’s picture

@webchick: The primary and most important part of this issue is to strip the "$module." prefix from the filename (see OP).

@all: Whether the filename is ultimately called extension.yml (or info.yml or meta.yml) is secondary (and borderline irrelevant).

@nod_: Yes, this also applies to themes. In fact, all extensions.

dww’s picture

sun: In a community as fixated on whitespace in code comments as ours (for better or for worse), you can't possibly expect anyone to take you seriously that filenames are "borderline irrelevant". ;)

-1 to "extension.yml" -- no where else in all of Drupal do we call these "extensions" (whether we should is a separate question, and has much farther-reaching implications than these filenames).

If we have to rename these at all (I'm not sure) +1 to info.yml.

But why do we need to "enforce" this constraint in the first place? There are a billions ways to break Drupal if you don't follow the rules. Why is this particular one worthy of something that would (potentially / in some ways) reduce the DX to enforce? We don't actually *enforce* that you have a .info(.yml)? file at all. But if you don't, Drupal doesn't find your code. So, if you don't follow the rules, your stuff is broken. Big deal. Follow the rules.

klonos’s picture

#9 makes a lot of sense to me too. If we are to rename, then go with info.yml that includes the "info" word in the filename. "info" is there in previous versions and when I scan through a directory my eyes are accustomed to look for that word in the files listed. My point is that it's much easier to get the hint that changed to info.yml than to extension.yml.

tim.plunkett’s picture

We just renamed all template.php to $themename.theme, I see no reason to go the opposite direction here.

webchick’s picture

Status:Active» Postponed (maintainer needs more info)

Marking postponed (needs more info) on dww's #13. I also don't really understand why this is worth doing.

jibran’s picture

webchick’s picture

Status:Postponed (maintainer needs more info)» Closed (won't fix)
jibran’s picture

If we consider #8 as an option, will it still be a won't fix? For me it is a DX win that we have simpler file names. It is great for contrib/custom as well copy an existing module and just change internal content no need to rename the files.

tim.plunkett’s picture

#8 is a huge reason *not* to do this. We just changed template.php to THEMENAME.theme for a reason.
If everything was named routing.yml I would have gone completely 100% insane trying to do #1981368: Convert all routes to 'module_name.foo_bar' naming convention :)

Let's just leave this issue to die.

sun’s picture

The proper answer is to use composer.json files anyway.

Identical result, just a different filename and format.

tstoeckler’s picture

I don't see #8 as corollary of this at all. extension.yml is about extension discovery. Everything else happens if you've already discovered an extension.

tim.plunkett’s picture

If I open 3 extension.yml files in a text editor, it becomes increasingly confusing which is which.

But it doesn't matter, this is closed.

tim.plunkett’s picture

Issue summary:View changes

Updated issue summary.