watchify support?

[focusaurus]

How about integrating watchify (or similar) to detect fs changes during development, invalidate the cache, and trigger a rebuild and recache?

Before I found browserify-middleware, I had a snippet like this that did it for me:

function cache() {
  build().pipe(concat(function(buffer) {
    module.exports.prebuiltCache = buffer;
  }));
}

if (config.browserifyDebug) {
  bundle = require('watchify')();
  bundle.on('update', cache);
}

Usually by the time I switched from my text editor to my browser and reloaded the page, the new bundle has already been built and cached so it's still fast.

[ForbesLindesay]

We've actually had this for ages. We take a slightly different approach (we check all the time stamps of the files every time someone attempts to load the file). The advantage of this approach is that it's completely cross platform. You always know you're looking at the latest version of the file. This contrasts with the watchify approach, that can leave you a second or two behind on windows systems. By only re-compiling changed files, it's pretty fast.

[focusaurus]

Great, thanks. Seems to be working pretty well.

[raine]

Why does it with cache: "dynamic" still take over a second to get a bundle without any changes between requests?

[ForbesLindesay]

Not sure, it shouldn't really take that long. It will still have to fs.stat every file that is included in your bundle to check the updated date. Browserify also still re-builds the bundle, it just doesn't then have to parse any files that haven't been updated. Of course if you have something that updates the time stamps, it will show up as an update even if there are no actual changes. You could try cache: false and see if that's slower/faster/the same.

[raine]

// cache: false
GET /editor/bundle.js 304 - - 2928 ms
GET /editor/bundle.js 304 - - 2134 ms
GET /editor/bundle.js 304 - - 2423 ms
GET /editor/bundle.js 304 - - 2190 ms

// cache: true
GET /editor/bundle.js 304 - - 3226 ms
GET /editor/bundle.js 304 - - 1 ms
GET /editor/bundle.js 304 - - 1 ms
GET /editor/bundle.js 304 - - 1 ms

// cache: dynamic
GET /editor/bundle.js 200 2337364 - 2524 ms
GET /editor/bundle.js 200 2337364 - 534 ms
GET /editor/bundle.js 200 2337364 - 526 ms
GET /editor/bundle.js 200 2337364 - 551 ms

Is around 500ms normal?

[ForbesLindesay]

I think that sounds pretty reasonable. If it's truely the case that nothing has changed, you should still get the 304 response though.

One way that we could probably reduce that time would be to exclude node_modules from what we check with cache: dynamic. Without a way to detect when npm install has been run though, I'm not sure that's a great idea.