Cache isn't invalidated if transform options are changed

[jameslnewell]

I'm using the envify transform and uglify to remove dead code.

.transform('envify', {
    global: true,
    NODE_ENV: process.argv.indexOf('--production') !== -1 ? 'production' : 'development'
  })

When the NODE_ENV property is changed between runs, browserify-incremental still uses its cached version of files which produces a different output to what is expected.

---

Is this fixable in browserify-incremental? Otherwise, before I run browserify-incremental I need to delete the cache file when NODE_ENV changes between runs and that means storing state somewhere. :disappointed:

[jsdf]

To fix this, environment and configuration need to become part of the cache key (which we should have always been doing 😬). This is not yet implemented, but it's my first priority.

[jameslnewell]

Awesome! Can you clarify what parts of the environment and configuration would become part of the cache key?

I've got around the issue for now by not using browserify-incremental for "prod" builds at all.

[jsdf]

Basically when items are stored in the cache, currently they are keyed by file name only. If that key also included a digest of things like the node env and browserify opts, then when those things change, that cache entry wouldn't be used.

[aquach]

Would it work to mark the NODE_ENV in the browserify incremental cache? Like cacheFile: './browserify-cache-' + NODE_ENV + '.json' roughly?

[garthk]

Won't help with changes to transformation or plugin settings in package.json or the browserify command line, @aquach. @jsdf' approach of invalidating if the config changes makes sense.

[xaviergonz]

maybe it could make a json of the options, make a base64 sha1 hash out of that string and append that to the cache file name? that way the cache file would match the same (and only the same) options.

The cli could do the same technique with it is command line argument string.