Open balupton opened 10 years ago
tkellen
commented
10 years ago I really appreciate you taking notes and dropping them in the wiki, Ben!
RobLoach
commented
10 years ago If I read this correctly, looking at grunt-contrib-cssmin, we may end up with a number of different npm modules:
| npm module | Description |
|---|---|
| clean-css | The Logic |
| node-tasks-cssmin | The Node Task |
| grunt-contrib-cssmin | The Grunt adapter for node-tasks-cssmin |
| gulp-cssmin | The Gulp adapter for node-tasks-cssmin |
| docpad-plugin-cssmin | The DocPad plugin for node-tasks-cssmin |
In essence, this would abstract the way generic configuration-driven tasks are handled, allow the same business logic across all different platforms. Grunt, Gulp, DocPad, it wouldn't matter as all of them would use the same node-tasks-cssmin configuration spec. This eases the maintainability of each module, as well as reduce the amount of duplicate code across modules.
In the meeting between Grunt, Brocolli, DocPad, and Gulp, there was a pre-supposition that our tasks/plugins/scripts (adapters) are duplicating effort, because the plugins are trying to do the same thing.
Jo challenged this saying that most adapters are really simple, in which BenA replied that things like sourcemaps makes them really complicated. Both are true in my own experience. Our CoffeeScript adapter is a few lines, but our SASS plugin are many more due to sourcemaps support.
However, I fail (at this point) to see how having one adapter for each library, will actually reduce effort, or perhaps be possible.
For instance, DocPad works with buffers, Gulp works with streams, Grunt works with files. Each of these are fundamentally different at this stage. Each go about what they do differently, in simplified terms; DocPad uses an in-memory database, Gulp takes stream input and outputs stream output, Grunt takes configuration, and reads and writes files. Each of these require different contexts, hence why we each have our own adapters, to allow a common module, e.g. a rending engine, to actually be able to be applied to our applications context.
For things like DocPad's SASS plugin. It is unfortunate that it is so complicated due to the sourcemap support (among the support for compass, requires, stdin, files, etc). However, I don't see the solution to this complication, to be having a unified task spec.
Lets say right now, to provide an example, I have the project bevry/projectz, I mentioned this to a grunt user, and they said that they wouldn't use it because it isn't a grunt task, the wording here is very very important. When I said that you could include projectz as a npm module, into a grunt task, they were confused. Which then lead me to drawing the following:
In this sketch we have DocPad, Grunt and Brunch, all each with an overlap with NPM Modules. In the ideal, the overlap is the adapter, and the npm module is a generic npm module that makes writing the adapters trivially easy.
For instance, let's take the docpad feedr plugin. If I were to make this as a grunt task, or as a docpad plugin*, then the feedr functionality would actually be inside the task, and then only compatible with systems that implement that task framework. E.g. grunt tasks only work with grunt, you can't just npm require them into another npm module without also requiring grunt and setting up grunt and all that (same goes for DocPad currently).
However, in the case of the feedr plugin, we actually have all the heavy lifting abstracted out into a generic npm module that any task, module, whatever can use. https://github.com/bevry/feedr — making our actualy docpad feedr plugin, trivial. It is simply an adapter for the module.
So there are really few ways proposed that we can take this:
Personally, I like 1 and think it is the most freeing, applicable, and instantly implementable solution. Grunt tasks should be trivially simply, as all the heavy lifting should be there own module. I shouldn't have to have a grunt configuration file, I should just be able to do
require('some-grunt-task')(someGruntConfiguration)and be done.2 I think will suffer from all the exact same problems as grunt and docpad currently face.
3 I think is a good option that we are already working on. DocPad plugins are already really generic and well documented. They can theoretically work without DocPad already, but it just isn't well documented nor supported. It will probably take a week or so of work to make our entire plugin system generic so anything can use it, but right now there is no need to do so. But it would certainly be cool.