Add-on Scaffolding

[gregrickaby]

On our Thunderdome yesterday, @colorful-tones suggested scaffolding BuddyPress, WooCommerce, SassDocs, etc... like the WDS Plugin Generator.

Would love to remove some of the more custom elements of wd_s out of the box, and instead make them available as an "add on" via Gulp.

The command would be something like:

gulp add woocommerce

It would tell Gulp to add the usual WooCommerce template files and associated Sass.

[colorful-tones]

For the record I recommend we use Yeoman, and would also suggest we start project as new, blank slate. Therefore, we would have a parent WordPress skeleton generator that would generate a barebones theme, think _s, but stripped down even further. Then have sub-generators to add Sass, JS configs, BuddyPress, WooCommerce, SassDoc, Animations.scss, and even Bourbon/Neat.

I think it would be beneficial on many levels to start from scratch with a blank slate, and perhaps reference wd_s along the way.

[gregrickaby]

I love this idea.

Creating a Yeoman generator for "projects" needs to be the long term solution. The "project generator" would replace the "plugin generator" and include a "theme generator" (as well as several sub-generators).

This idea though, will require a conversation between @bradp and the rest of the Leads.

In the meantime, I think we can try to create a nifty sub-generator using (Gulp) https://www.npmjs.com/package/slush or https://mozilla.github.io/nunjucks/

[binarygary]

👍

This is a thing I was thinking about to some extent but not quite so deeply.

The plugin gen (yeoman) and the wdunderscores.com are both pretty strongly colored by the anticipated user.
Even a simple wrapper of some sort that handled both generators would be a very cool first step.

A true "Project Generator" that takes into account things like ACF/CMB2, plugin load priority (see https://github.com/WebDevStudios/generator-plugin-wp/issues/100), required plugins (heck why not a list of plugins we pull by default?) and becomes the authoritative record for i18n string would be super handy.

The nature of wd_s is that it is run 1 time per project.
The plugin gen is (very often) run multiple times/BED/project. I think that leads to 3 distinct repos: wd_s, plugin-gen and finally a project generator.
It will require agreement and standardization in how we share common libraries.

Fair to say step one is an open issue (https://github.com/WebDevStudios/generator-plugin-wp/issues/99) on the plugin gen. Lets see how and where that goes?

[gregrickaby]

After spending a considerable amount of time with Docker on a client project, I wanted to leave a note about my experience. IMHO, a project generator would require us to maintain two versions of wd_s. A "generator version" and then one like this repo (downloadable and ready to use).

Instead, we could just start a WDS Project container. This Docker container would use Composer and NPM/Yarn to manage libraries and could even do things like kick off the plugin generator, install WP CLI, and even sync with Lab.

Then spinning up a local for a new project would look something like: $ composer install && npm install && docker-compose build wdsproject && docker-compose up wdsproject

Using containers ensures the entire team is running the same development environment, means setting up a local takes a few (automated) minutes, and maintaining a single set of code on Github which would be included and generated via Composer.

This is totally out of scope for this Github ticket... but wanted to leave a note anyway.