To be specific, this isn’t so much a gripe with Yeoman as it is a gripe with the way in which some people use open-source Yeoman generators. As I’ll discuss at the end of the post, Yeoman is an amazing tool which can yield incredible results in decreasing development time, but only when used wisely. So before we get too inflammatory, I should say that I’m a huge fan of the Yeoman project.
The Rails Generator
Before we talk about Yeoman, let’s talk about Rails. One of my favorite tools in all of Rails-dom is the built-in Rails generator. It’s simple, flexible, and helps you adhere to the rules of Rails. And that’s important because those rules aren’t easy to remember.
On top of which, you can auto-generate as granularly as you like, or as full-bore as you like. You can create each individual piece of the resource you’re trying to develop, or take advantage of the full-suite of generators by building an entire CRUD resource in one command.
Why it makes sense in Rails
Rails is an angry framework. Violate any of its rules and you break Rails. Which file names have to match in which directories? Which classes can be plural and which can’t? These are all important details when developing a Rails application, but only because they are restrictions put in place by the Rails framework. These are not details that dictate business logic, nor are they best-practices that help us write clean code. Essentially, they’re the last things we want to think about as we’re building a complex application. Which is why it’s nice to be able to pawn that work off to a command-line tool.
Let’s Talk About Yeoman
Now that we’ve discussed a generator that works and works well, let’s talk about generators that don’t – or rather, use cases that don’t. Whenever I see a Yeoman generator in use, it’s usually used to build an Angular project by a team that doesn’t know Angular. Not knowing Angular isn’t a bad thing. Assuming that the Yeoman generator can make all the decisions for you – that’s a bad thing.
Every time I see this happen, it’s done with an open-source generator like the Yeoman team’s Angular generator, or the widely popular Angular Fullstack. While these are impressive projects that can do a lot of cool things, they are certainly not all things to all of Angular, as the link at the top of the Angular generator’s readme would suggest.
“That’s how the generator does it”
On several occasions I’ve been asked to help debug problems on an Angular project, only to find out that the person asking for help can’t even give me a tour around the project. If I ask questions about things like why they have empty test stubs in every one of their modules, or why they have a flat module structure when the functionality of the application clearly dictates a hierarchy to their Angular modules, the answer I generally get is “That’s how the generator does it”.
In fact, the worst argument I think I’ve ever heard for using a Yeoman generator on an Angular application was focused on the fact that it thinks through all of the file structure for you – something which should be specific to the dev team, and should probably be dictated by their process and standards rather than a file generator.
Sometimes, you even get unintended results, like when a Yeoman generator has a built-in Grunt workflow to remove relative links to dependencies and replace them with CDN calls. If you don’t know that’s in there, it can lead to some pretty big problems in production – like if you’re behind a firewall and the CDN domain isn’t explicitly granted access by your security team, or if you’re building an offline-first hybrid app which needs to have all of its dependencies stored locally.
All of these point to the same basic problem, which is that often times people use Yeoman generators without any understanding of what the generator is doing when it runs. Far too often I’m told that a Yeoman generator makes development easier, when really I find that the teams using it are hamstrung by decisions they don’t understand, made by a developer they’ve never talked to. The team never takes the time to form their own decisions, or even investigate how or why someone else formed the generator the way they did. Start asking questions, and the conversation – almost every time – leads back to “That’s how the generator does it”.
Why the same benefits don’t apply to Angular
The benefits of using a generator in Rails don’t necessarily translate when working with the front end. First of all, the file structure in an Angular application is entirely ambiguous – as it is in any front-end application. File paths don’t matter to the application runtime as long as they’re accessible from the
index.html, and the module declaration is injected before any methods added to that module. And that’s about it.
Second, there’s no “one way” to write an Angular application as there is with Rails, so a lot of the practices put in place on a dev team should come from discussions between the developers, not from a generator meant to make decisions for them. Different teams and different uses cases will dictate different practices. Some teams like to go with a component-based structure in preparation for Angular 2, while other teams just aren’t there yet. Some teams like to embed a lot of functionality in the front-end, while other teams consider the front-end a simple pass-through for data between the user and the backend. Again, it all comes down to how the team develops, and that should dictate decision-making.
How Yeoman Can Be Incredibly Helpful
All that being said, there’s nothing that’s stopping dev teams from writing their own generators to help each other build according to their specifications, and their standards. One of the common use-cases that I’ve found matches exactly the mentality behind the Rails generator.
Let’s say you work in company that has put a lot of time into developing best-practices within its dev teams, has a specific way of wiring applications together, and has a very clear definition-of-done. In that case, writing a generator that will help speed up the dev process would be very useful. That way each member of the team can use it, add to it, and give feedback when it doesn’t fit their use case. It grows naturally within the team, on the applications that it’s meant to help build.
This goes even further when your team is building a framework of development platform that has a lot of rules – as you might find with Rails – something you’re very likely to see if your team has a lot of automated processes. Certain files – and even sometimes certain text strings – have to live in the same place every time in order to be wired together properly. In dev environments where that’s the case, it’s a lot easier to run a command to generate those files than it is to build them by hand and make sure everything fits accordingly. Automation prevents a lot of bugs that might be introduced – even by such simple things as capitalization, or misspellings.
Note that the big difference here is that this process not only suggests dev teams fully understand the decisions behind their development process, but also that they build their own dev tools to accommodate whatever it is that they decide on. That can be a big ask, I’m sure, but a necessary one when forming or improving a dev team’s processes. Just grabbing a generator and assuming that it’s making all the right decisions is like grabbing whatever WordPress theme has good reviews, and assuming it fits your business needs. It’s just not going to work out.
That all being said, I’m the first to admit that there aren’t very many resources available out there on how to get started with building your own Yeoman generator. It’s a shame, too, since it’s a great way for dev teams to all get on the same page. With that in mind, my next few posts will be about building generators with Yeoman. Look for those later this week.