Solidus-specific Grunt/Gulp tasks should be distributed as plugin(s)

[pushred]

Currently everything Solidus and Grunt is distributed through updates to the "reference" Gruntfile in this repo. This makes distributing any fixes or additions very difficult, as this file is a moving target and must be updated manually everywhere it's been installed, along with any package.json dependencies. Also, as the Gruntfile grows in size it's also increasingly daunting for developers to make any changes for fear of breaking anything.

The original implementation bundled the Gruntfile with Solidus itself but the whole point of the current approach was to allow for customization, particularly leveraging the vast number of plugins out there. This ability hasn't been used too often, but I'd hate to lose this option in order to address these issues.

Why not distribute the features that Solidus implements with Grunt to one or more plugins? Grunt plugins are like any other module, allowing for:

• Namespaced tasks
• Configuration objects
• Explicit dependency definition in both the Gruntfile and package.json
• Unit tests

A grunt plugin for our own tasks would just be another layer of abstraction while providing an effective blank slate for developers to add tasks of their own. By controlling the sequence of the Solidus tasks they could order their own tasks easily in front of Solidus and opt in and out of certain features (i.e. Sass compilation).

Since plugins are still distributed with npm we could opt to publish it or not to a public registry if that's of concern.

Maybe a switch to Gulp would be a good opportunity to rethink this. The implementation of Gulp plugins is pretty different because of streams, but the above qualities are still all true, with a less rigid structure.

[Fauntleroy]

Have you seen any plugins that run other grunt tasks? I'm not sure I've ever seen this approach before. I think this would also preclude me from doing the modifications necessary to things like KU.net, where I needed to mix in handlebars in a strange way. We really do need to find a better way of getting build process updates out, but I'm not really sure what it is.

While a plugin might not be the best solution, we do need to fix this issue. Perhaps we could move these compilation steps back into solidus itself somehow? This way we could get rid of the annoying update-this-then-update-that workflow we have going with solidus and the solidus-site-template.

[pushred]

There's no more need for strange mixing is there?

You could at the very least load tasks from Solidus, which maybe might need to be defined as a peerDependency. The official plugins do this to stay sane, and grunt-contrib-internal is used to share code between them — a build process only, from what I can see. They also use grunt-lib-contrib to try new tasks proposed for core. This blog post shows another approach, wiring everything up automatically from package.json. There's all sorts of ways to clean this up and share code without abstracting the Gruntfile away and locking developers out of the ecosystem.