This is a text version compliment to the YouTube video of the same name. You can watch the video using the embedded player below.

Manufacturing jobs and supply chains are rife with examples of just-in-time processes and Lean process improvement. The idea is that by eliminating waste you can increase efficiency, productivity, and ultimately revenue. Although current hiccups in the supply chain due to COVID-19 disruptions have certainly drawn into question the value of just-in-time when the proverbial poop emoji hits the processor fan, productivity gurus didn't build a multi-billion dollar industry out of fluff. Well… most of them did, but that doesn't diminish the value of quality process improvement and appropriate time management.

Software has always benefited the most from acronyms that dictate frameworks (e.g., SOLID, DRY), but software engineering in abstract (or in academia) is different that software engineering run by finance departments, project managers, and basically anyone else that gives you a deadline before giving you the actual requirements. In those situations, you're often stuck repeating the same tasks because slack time is non-existent, and it's during this slack time where you would normally build tooling to assist your own work process.

I'm a big fan of tooling, but a huge critic of one-size-fits-all tooling. Each company is unique and the tooling that you need to produce the appropriate business value is thus, also unique. Once you get your feet wet in a new job or a new project you begin to put the productivity puzzle together. Completing a project is one thing. Making a project sustainable is another. Once comfortable, you'll see areas that would benefit not from more user features, but from better tooling under the hood. This is where true software productivity is won or lost.

In most of my current projects (both for work and for pleasure), I use very similar tools, frameworks, configurations, etc. With Node.JS applications, a lot of times this means loading in the same packages and copying the same configuration files all over the place. Whether in a monorepository or a brand new repo, this minimal step (although it might only take an hour or less) offers its fair share of time sinks, copy/paste errors, and various other issues.

This is where code generation comes in handy, but even more minimal that code generation is basic application scaffolding, and it's drop dead simple to do application scaffolding in Yeoman.

For a basic example, start by initializing a new project:

npm init -y 

You can fill in the details of the package.json file later.

For your application structure, you're going to need a folder called generators and a folder inside of that one called app. This tells Yeoman where to find your generator code and template. If you had multiple generators associated with this generator package, you could have multiple folders under the generators folder and app would be the default generator.

You'll need to install the Yeoman generator package. I also recommend installing the Yeoman package itself locally for debugging purposes, and since we're just doing something basic, you can get by with just installing fs-extra as an added dependency.

npm install yo yo-generator fs-extra --save 

With those installed, we can start building our generator. Do this in an index.js file in the root of the application directory (same directory that the generators folder sits in). Once you have this set up, we'll begin by creating our generator class.

const Generator = require('yeoman-generator'); const fs = require('fs-extra');

(more...)