this.state

[Rich-Harris]

I just released gobble-browserify 0.6.0, which uses browserify's caching mechanism (similar to watchify) for faster incremental rebuilds. It led me to a couple of thoughts:

• Currently, the only way to persist state between runs is to store it on this.node. This is bad - it exposes gobble's internals unnecessarily (plugins could come to rely on undocumented non-API stuff, because developers are sneaky like that), and a plugin could easily overwrite something important.
• Therefore, there should be a correct, documented way to do this - a this.state object which transformer functions can do whatever they want with
• This introduces (or rather, makes more explicit) a theoretical danger that if a build was invalidated while a transform (let's say foo) was running, the next foo could start before the original's completion, meaning that 'good' state (from foo 2) could be corrupted with 'bad' state (from the aborted foo 1). In practice this is unlikely, but over a long enough timeframe the unlikely becomes the inevitable. So invalidations should trigger a cleanup* before the build is restarted. (This also raises the possibility that we can do away with the numbered subdirectories, and just have cache and output subdirectories inside each transformer directory.)

Also, gobble-browserify currently has an unfortunate limitation: bundles are only invalidated when input files change, which isn't the same as when the bundle's dependencies change, if it has dependencies outside the input folder (i.e. in node_modules). Most of the time this is fine, since your node modules change much less frequency than your app code, but it's a nuisance when using npm link for example. Which leads me back to #26.

*by 'cleanup', I mean wait for all current transforms to report completion, then delete old output directories. Optionally, transformers could report completion early if some kind of 'aborted' signal happens - currently, there's a this.aborted flag used internally, but a documented event handler would be better:

var transpile = require( 'someTranspiler' );
module.exports = function myTransformer ( inputdir, outputdir, options, callback ) {
  var task = transpile( inputdir, outputdir );
  task.on( 'done', callback );
  task.on( 'error', callback );

  // something like this, perhaps
  this.onabort( task.abort );
});

[ammojamo]

+1 to this
I just implemented a custom webpack transformer and had a similar need to persist state in order to do incremental rebuilds.

[Victorystick]

I assume Rollup would benefit from this if incremental builds were to become a reality?

I had wondered how you'd solved the issue for gobble-browserify. Well, the chase led me here. 😜