Does an observer node make sense?

[evs-chris]

Something that can participate in the build process but doesn't necessarily produce any files. For instance, running a node app or linting. Using a directory transform means you either copy all of the files or leave the output empty and have a node that can't go any further.

For running a server, the directory transform approach seems to be ok, since you typically don't care so much about the output once it's kicked off. It might be pretty handy for a linter though, so it could fail the build and just pass its input dir downstream.

Or have I strayed too far from build tool into task runner territory?

[Rich-Harris]

I was thinking along similar lines recently. Initially I wanted to keep task runner functionality out of Gobble, because I felt that Broccoli's singular focus on being a build tool was its great strength and Gulp's desire to usurp Grunt was its great weakness.

But there's actually an interesting opportunity here, besides the fact that temporary directories are no longer needed for linting/testing intermediate files: observers/checkers/runners/whatever we call them could take advantage of the same caching mechanisms as transformers. That could be pretty powerful with #25 - e.g. you could choose to only lint files that have changed, or come up with a way to only re-run tests that could have been affected by a change. I think these things are pretty tricky to do otherwise (though some Make fanatic is probably about to leap out from behind a bush and say 'well actually...')

I'm still slightly ambivalent though - I think we'd need to be sure that the opportunities outweighed the costs.

I love the gobble-node-server idea. Maybe that use case should be given first class treatment? See also #9.

Some prior art: a previous version of Gobble had an inspect method - the idea being that you wanted to dump the contents of some intermediate step to a specified folder, and keep it updated:

var styles = gobble( 'src/styles' )
  .transform( 'sass', sassOptions )
  .inspect( 'tmp/styles' );

// ...
module.exports = gobble([ root, src, styles ]);

In other words the .inspect() call didn't affect the build at all, it just returned this. Am planning to reinstate it (#18).

[Flaise]

I'm still slightly ambivalent though - I think we'd need to be sure that the opportunities outweighed the costs.

Gobble's current concept of a 'node' is something that is given an intermediate or initial state of a directory as input and generates a new state of a directory or an error as output. What Chris is calling an 'observer' node is something that is given an intermediate or initial state of a directory as input and generates either nothing, a side effect, or an error as output. If any tool is going to be ideal for this purpose, it's a future version of Gobble designed for the purpose because the concepts are so orthogonal.

Hypothetical use case:

initial state
|> linter
|> es6 to es5 transformation
|> unit testing
|> Browserify or some equivalent
|> minification
|> copy to output directory

Two of those nodes don't transform the output but only analyze it and sometimes generate errors. The reason this is relevant to Gobble is because sometimes these analysis steps need to be interlaced with transformation steps - in particular, you may want to perform unit testing /after/ transforming the code so that it works on a browser and yet /before/ bundling and minifying it so the stack traces don't turn into a weird alien language transcribed into the Roman alphabet. And of course the steps that aren't somewhere in the middle still benefit from the file watching - it's nice to not have more tools installed and in use than necessary.

[Rich-Harris]

Yeah, the more I think about it the more I like this idea. An obvious example is the ractive build process, where we eat a lot of gobble dogfood - right now, it lints, then builds with gobble, then runs tests. If the tests pass we're back in build tool territory, but at that point it's much simpler to do the final steps (minification and sourcemap tweaking) as shell commands.

It would definitely be much better if the whole sequence could be described in a single file and in a single language, since build and non-build tasks are often so intertwined. Am keen to look into this more closely in the near future. Thanks for weighing in.

[msegado]

(should this issue be closed now that #44 has been merged?)

[Rich-Harris]

Good catch @msegado, closing - thanks