A recurring critic leveled at D8 (again today on a blog, but also received from customers and part of the original Backdropcms manifesto) is the sheer number of files.

There is one specific change in that regard which should not require much and could go a long way towards making "first contact" less brutal for developers, and that would be bringing in all module-root YAML files (module.info.yml, services.yml, routing.yml ...) as documents within a single module metadata file, probably module.info.yml).

  • Pros:
    • overally, easier to find information at a glance even without knowing where to look and /also/ when knowing where to look
    • allowing more newbies to just write their first "hello world"s with less files
    • less crowded module directory reducing silly critics about file count
  • Con:
    • past code freeze (gelato ?)
  • Precedent:
    • During earlier versions, we used to have separate .schema files (PHP), much like we now have config/schema/*.yml and they got moved to .install with the rest of the install hooks, in much the same vein.

Comments

Xano’s picture

Xano
he/they
Primary language English
Location Southampton
CreditAttribution: Xano commented

silly critics

Exactly.

I'm inclined to disagree, because we'll then have a single file with a lot of different types of information. *.info.yml files contain plain module metadata, *.local_task.yml files contain plugin definitions, and *.routing.yml files contain routes. These are just three examples, but the formats and what the types of data represent are completely different. Merging these will make the one file a terrible mess, especially when contributed modules want to use YAML discovery as well.

Xano’s picture

Xano
he/they
Primary language English
Location Southampton
CreditAttribution: Xano commented
Issue tags: +DX (Developer Experience)
fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm commented

After discussing this a bit with Xano, here is a sample file combined yaml file for field_ui, showing how it could look.

The basic idea is to keep the configuration in separate documents to avoid semantic confusion, but use Yaml's multi-document-per-file capability ("---" separation, see http://en.wikipedia.org/wiki/YAML ) so that these independent yaml documents are stored in just one file, only reducing the number of files without changing the actual document structure.

# Info
name: 'Field UI'
type: module
description: 'User interface for the Field API.'
package: Core
version: VERSION
core: 8.x
dependencies:
  - field

---
# Routing
field_ui.list:
  path: 'admin/reports/fields'
  defaults:
    _entity_list: 'field_entity'
  requirements:
    _permission: 'administer content types'

---
# Services
services:
  field_ui.subscriber:
    class: Drupal\field_ui\Routing\RouteSubscriber
    arguments: ['@entity.manager']
    tags:
     - { name: event_subscriber }
  access_check.field_ui.view_mode:
    class: Drupal\field_ui\Access\ViewModeAccessCheck
    tags:
     - { name: access_check }
  access_check.field_ui.form_mode:
    class: Drupal\field_ui\Access\FormModeAccessCheck
    tags:
     - { name: access_check }

Again, this is mostly a matter of perception of our code than of code itself.

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm commented

Related/affected issue: #2065571: Add YAML Plugin discovery.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

It would be great to keep local tasks/actions/contexutal links separte from the routing ones

One thing we could also do is not keep menu/routing related things together and low level things like services/$module.info.yml/(maybe event subscribers in the future).

Grouping menu related things though has the potential that people mix up routing with menu stuff again and we end up in a D7 like situation.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett commented

I think that either *everything* needs to be in one place, or everything should be kept separate.
The most important thing is to not have groupings that conflate truly unrelated concepts that might have been conflated in D7, as @dawehner said. Unless all YAML is in one file, we *must* keep routing separate from contextual links/local actions/ local tasks

samhassell’s picture

samhassell CreditAttribution: samhassell commented

Another con could be file size when dealing with large contrib modules. However I think having to keep track of open more files in an editor or IDE sucks. One combined file is far more convenient.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

so, just make these all part of the info.yaml file? In the example by fgm I don't see how I can differentiate the different documents - the comments won't be included.

I also don't really love this since it means you have to parse and build many different YAML docs any time you might be looking for one?

neclimdul’s picture

neclimdul
He/Him
CreditAttribution: neclimdul commented

There is a flip side to consider. One large combined file is only more convenient when it has the things you need. Once it gets too large and has too many mixed concepts its worse because of the size of the file and the complexity. This is why we've been splitting things out of .module files since forever. I assume though that's why the title says "Reduce" not "use one file" :)

Another con, this will likely add complexity to the YAML discovery components and/or require additional Discovery objects which swings a different DX marker.

Personally I don't have a problem with the current state. As has been noted, the concepts are clearly separated into useful buckets. We're not requiring a YAML file for each menu task or anything like that. And having played with converting some local tasks, the annoying part was having to have .module open and finding hook_menu() and parsing it out and dealing with the size of the routing files which are already a good size. Making them larger wouldn't help. :)

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm commented

It's true that you don't get names on invidual documents, unless you use some key in them, like a top-level key in each, AIUI.

However regarding the "parsing many different docs", I suspect this would actually be a net win ; think read-ahead pattern for I/O: looking at all documents from a single file in one pass with one parser is very likely to be cheaper than parsing separate files, and they can be kept in static cache in case they are needed for the next access to one of the documents during the same request.

But this is really more about improving ease of use for (fledgling) developers more than anything else.

neclimdul’s picture

neclimdul
He/Him
CreditAttribution: neclimdul commented

I doubt performance is really worth discussing since these are already slow and avoided on critical paths. Especially when this is a DX issue as indicated by the tags.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
CreditAttribution: larowlan commented

Definite -1 from my point of view

Xano’s picture

Xano
he/they
Primary language English
Location Southampton
CreditAttribution: Xano commented

Isn't the data of (most of) those files cached after it has been retrieved?

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

Isn't the data of (most of) those files cached after it has been retrieved?

Sure all of them, even on multiple different levels.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

-1 from me - I think the complexity of trying to combine all these in one file then parse them out again (by hand for developers, or in code) far outweighs any gain. Right now you can see at a glance what's going on based on what files are present.

Was discussing with sdboyer yesterday a way to more readily auto-generate routes which could remove some of the routing.yml files, but then points to the need to have tools (ideally in core) to help you inspect Drupal's data rather than assuming that everting is in fiels (which is won't be even now since there are dynamically created routes, etc).

damiankloip’s picture

damiankloip CreditAttribution: damiankloip commented

Also don't agree with this... Having stuff split makes them easy to manage, as well as being clearly separate things.

Having one yaml file using separators will mean they have to be in a particular order or something? Because that sounds way worse.. And seems like we won't gain anything, especially not any DX improvement.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
Status: Active » Closed (won't fix)

I think this is a "won't fix"

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm commented

That seems to be the consensus indeed.