Yeoman Generators for Drupal: What’s out there?

drupal logoyeoman-logo

 

I’ve been hearing about Yeoman for quite some time now. Pretty much since the project took off, or soon after. As a tool born in the Javascript community, I came across this little gem when I was learning about Node.js and the different tools and frameworks available for it, either in my free time, or as part of my labs time at my company. Sadly, I didn’t really pay much attention to it. At the end of the day, Node.js was just something I was learning about, but not something I was going to be able to put in place or introduce in projects in the short term. Or, even if it was something I *could* do, it wasn’t in my plans, anyway.

The other reason why I didn’t look into it closer, was that I mistakenly thought it to be a tool only useful for Javascript developers. Some time ago I noticed that Yeoman was getting plenty of attention from other communities too, and in a closer look, I understood that it wasn’t a tool for Node.js, but instead, a tool built on top of Node.js, so I decided to give it a try and see if I could make something useful out of it for Drupal development.

Warming up…

So, what’s Yeoman then? It’s a code scaffolding tool. That is, it’s an utility to generate code for web apps. What’s the purpose of that? Well, the purpose is that developers save time by quickly generating the skeleton of the web apps they build, leaving more time for the important things, such as the most complex business logic of the app, integrations, testing, etc… In short: it’s a tool that should help developers deliver more quality in their apps. To get a better picture of what Yeoman can do, I’d point everyone at their site, which has some nice tutorials and a very good documentation for writing your own generators.

My plan was to write a few generators for the most common pieces of boilerplate code that I normally have to write in my projects. Unsurprisingly, I found that there are a few yeoman generators for Drupal already out there, so I thought I should review them and see if they’re of any use to me, before writing one that already exists. Yes, that can be a boring task if there are too many generators, but I was lucky that there aren’t *that* many for Drupal, so I just spent a couple of hours testing them and documenting my findings. Hopefully, this blog post will help other Drupal developers to find out in a matter of minutes whether the existing generators are useful for them or not. So, let’s get into it!

1.- Generator-drupalmodule

Github repository hereCreation date: Around 2 years ago.

Structure created:

This one scaffolds a basic structure for a simple module. Needs bower and a package.json file to download dependencies, but not a problem anyway since you’ll probably have drush. Creation is a bit unintuitive: you need to create the module folder first, cd into it, then execute yo drupalmodule.

The generator asks if you want JS and CSS files, but it doesn’t even add functions to add them to the page. It’s a generic purpose generator, and doesn’t have anything that is not in module_builder already.

2.- Generator-drupal-module

Github repository hereCreation date: Around 2 months ago. Latest commit about 2 weeks ago.

Structure created:

More neat than drupalmodule in the surface, but doesn’t do much more. It asks us if we want hook_theme(), hook_menu(), hook_permission() and hook_block_info / view implementations, which is nice, yet that doesn’t make it much of a gain compared to other simple scaffolding tools, like PhpStorm live templates. In contrast to the drupal-module generator, this one doesn’t ask us if we want a CSS or JS file.

3.- Generator-drupalentities

Github repository hereCreation date: 9 months ago. Latest commit about 6 months ago.

Structure created (“publisher” entity):

Views and license files are optional, based on the settings specified in the command-line.

Generates a full drupal module for a custom entity, based on the structure proposed by the model module.

One issue I experienced is that if I select to “add bundles”, the Field API screen seems broken (doesn’t load). However, a general “fields” tab appears, but if you try to add a field, you get some errors and get redirected to a 404. So, bundles are offered on the plugin creation menu, but not really supported! Same for revisions. It’s asked on the command-line prompt, but doesn’t seem to do much. Not choosing bundles support, still lets you add bundles on the admin UI, and doesn’t seem to break anything, though.

In spite of the issues I had testing it (I didn’t bother much investigating what was the issue), it seems to me an useful generator. The only reason why I doubt I’ll be using it, is that it’s based, as mentioned, on the model project for Drupal, which is quite nice, but rather outdated now (4 years old), and doesn’t leverage some of the latest Entity API goodies. Also, I’ve developed some opinions and preferences around how to structure custom Entity Types, so starting to use the model approach would be, in a sense, a step backwards.

4.- Generator-ctools-layout

Github repository hereCreation date: 5 months ago. Latest commit about 14 days ago.

Structure created:

Generates a ctools layout plugin folder structure, with all the files needed to get it to work out of the box. It makes no assumptions about how the content will be displayed, so there’s no styling by default (which is perfect), and it allows to specify as many regions as desired. It’s quite likely that I start using this in my projects. No cons or negative aspects to mention!

5.- Generator-gadget

Github repository hereCreation date: 1 month ago. Latest commit about 1 month ago.

This one, rather than a code generator for Drupal elements, is a yeoman generator to serve as an scaffolding tool for another repo from Phase 2. While I didn’t get to test it out, the grunt-drupal-tasks repo really looked interesting (check the features here), and I might try to give that a go, although I’m familiar with Gulp and not with Grunt. Long story short: very interesting project, but it’s not meant to scaffold any code for your drupal modules.

6.- Generator-drupalformat

Github repository hereCreation date: 6 months ago. Latest commit about 3 months ago.

Structure created:

This one is very specific, tailored to provide views and field formatters for jQuery plugins, and it’s based on the owlcarousel module. It’s very useful if what you’re looking for is to easily integrate other jQuery plugins with your Drupal site. Very interesting generator, as it’s focused to scaffold the most repetitive parts for a very specific task, instead of trying to be a very generic solution that covers many things. You can see another great example leveraging this generator in Echo.co’s blog, for the jQuery Oridomi plugin. Not something that I have to pick up daily, but I’ll definitely have this plugin in mind if I have to integrate new Javascript libraries.

7.- Generator-drupal-component

Github repository hereCreation date: 6 months ago. Latest commit about 3 months ago.

Structure created:

I found this one rather peculiar. The boilerplate code it produces is rather basic, yet offers options such as creating a views style plugin by default, or a ctools content_type plugin. The good thing is that each component can be generated individually, which is rather convenient. The only issue that keeps me from using it is that, again, none of the components offer any options particularly advanced that could benefit from having an interactive tool like Yeoman (e.g: asking whether the ctools content type plugin will need one or more settings forms). For my particular case, I can generate all of these easily with PhpStorm live templates or template files easily.

Is that all, folks?

Ye… no! There are indeed a few more generators thought around drupal projects in the Yeoman registry (click here and search by “Drupal”). Some of them are very interesting, to do things such as:

However, I decided to leave those out of an in-depth review because, as interesting as they are, they cover several aspects of Drupal development, and people often has very specific preferences about how to structure a theme, for example, or what tools to use in order to create a Headless Drupal. 

Since the goal of this article was to give a bird’s eye view of what generators Drupal developers can use right now without changing anything in the way they work, I preferred to describe mainly the generators done around drupal modules, and more specific components. Hope this blog post has saved you some time. Expect to see a new one on this topic as soon as I’ve written my first Yeoman plugin.

8 thoughts on “Yeoman Generators for Drupal: What’s out there?

    1. Salva Molina Post author

      Hey Matt, thanks for your comment.

      Yes I’ve linked Hedley as well, in the bullet list towards the end of the article. That’s one of the plugins I didn’t describe in detail as it’s focused on a whole Drupal environment and not on specific components for developers, but I *really* want to give it a go, too!

      Reply
    1. Salva Molina Post author

      Heh, funny you ask that Matthew. As I was finishing the post, I thought I should maybe write another one about that point!

      I think it’s nothing too particular, but I like to:

      * keep entity classes and entity controllers into separate files (1 for each).
      * Extend “EntityDefaultViewsController” with a Base views controller for the project, and then make each entity has its own views controller for other specific properties.
      * Have a separate class for each entity, to deal exclusively with db queries (e.g: MyClassQuery) (all methods are static, so there’s not instantiation of objects whatsoever here. (Note I work remote, so I find that an obvious way to make sure everyone knows at a glance what helper functions are available already).
      * (I’ve recently changed my mind about the point above, in favour of a “Factory” class just to retrieve custom entities based on different filters (either field filters or custom properties, etc), and keep the “Query” class exclusively for certain bits of info that don’t require to load the whole entity.
      * Have forms in a separate “forms” folder, and also, split them by entity type (this sounds obvious, but in some cases we might have more than 1 entity type per module), having 1 class for each (extending http://drupal.org/project/entity_operations).
      * Have a base Entity class, extending “Entity”, and then for each entity type, extend that base class for the project, which contains the common logic tied to every entity of the project.

      That’d be more or less it. It’s worth noting I’m using this structure in a project where the entities have plenty of custom logic in classes and controllers, so I wanted to make things as clear and small and possible. I’m aware for simpler cases where there’s little coding, and the Entity type is mostly used just as another model in the database to store data, this might be overkilling.
      It’d be interesting to know how people are working with custom entities on their projects, too!

      Reply
  1. tsphethean

    The other one to consider (although not Yeoman) is the Drupal Console being built for Drupal 8 – http://drupalconsole.com/. It includes a bunch of “generate” commands for generating different things you might want boilerplate for D8.

    Reply
    1. Salva Molina Post author

      Indeed! I didn’t cover Drupal 8 console as it’s something many developers could benefit of right now (they technically can. I mean not many agencies, if any, are building sites in Drupal 8 yet), but it’ll be certainly a great step ahead.

      Reply
  2. Anders Grendstadbakk

    Hi,

    Author of generator #2 here, thanks for mentioning my generator 🙂

    I’m just wondering what kinds of features you think would be “must-have” in a Drupal module generator?

    I’m asking this because I think that if I add all core hooks to it, there will be to much configuration.

    Reply
    1. Salva Molina Post author

      Hi Anders,

      Thanks a lot for commenting, it’s great to see authors of these generators stopping by to leave their thoughts.

      I thinks that’s a good question, and possibly the “must-have” features are 100% subjective here. For example, in my team we base our projects mostly in ctools & panels, so we end up writing quite some ctools plugins (content_types -aka panel panes-, context plugins, content_panes, etc). As such, the options around ctools & panels options would be a “must-have” for us. Is it for you, if you follow a different approach or use a different set of tools? I doubt it.

      So I fully agree with you in that if you’re not using those things, there might be too much configuration. And, ctools aside, of course adding all core hooks would be maybe too much. Most of them are certainly less frequently used!

      I’d be interested in seeing an approach like that of the Generator-drupal-component, which offers everything by default, but then it has subgenerators to create some things individually. Maybe having some kind of “module type” generators as “subgenerators” would make sense. But just thinking out loud here.

      The main point here is, to me, that it’s great to see Drupal people getting off the island in these kind of things too, and using tools of the Javascript community to improve the way we work =).

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *