Using the same cache from multiple entry points creates invalid bundles

[kirbysayshi]

I doubt this is something that is fixable easily, and probably not within the purview of browserify-incremental. I also don't have a test case (I know, this is a cardinal sin)...

But I have a project using the following structure:

- views
  - view1
    - i18n.js (content A)
    - index.js (does not require lib1)
  - view2
    - i18n.js (content A)
    - index.js (does require lib1)
- node_modules
  - lib1
    - locales
      - index.js (content A)
    - index.js

Files marked as content A have the same file contents, but are at different paths.

and the build script is basically:

$ browserifyinc views/view1/index.js -o build/view1.bundle & browserifyinc views/view2/index.js -o build/view2.bundle

Notice how the browserifyinc commands are running in parallel-ish. When I execute the view1.bundle, I get a very strange error:

TypeError: undefined is not an object (evaluating 'arguments[4]["./node_modules/lib1/locales/index.js"][0]')

Doing some digging it appears that it may be related to browserify's deduping of modules with identical contents: https://twitter.com/KoryNunn/status/435198784146927616.

What appears to be happening is that browserify-incremental (or browserify?) is deduping the module contents to a module that doesn't end up existing in the final bundle! view1 never requires lib1, but has a file with the same contents as a file within lib1.

I'm not sure if the concurrency is the issue, or simply the similar file contents with different entry points. Browserify may, for example, be assuming that whatever is in the cache is valid for inclusion in the bundle.

Again, this is probably a weird edge case (or maybe not? perhaps it's all shared caches?), and I don't have a test case, and I don't expect a magical fix. But I wanted to share some info in the event that someone else finds this same problem. Also if there is anything that jogs your mind as to the real problem here, I would be very grateful!

Thanks for listening.

[jsdf]

This might be fixed by the changes in v3.1.0, give it a go?

[kirbysayshi]

@jsdf it appears to be "fixed" in that the cache is no longer corrupted (at least as far as I can tell). But incremental builds actually take longer using a shared cache now vs separate caches :)

I don't know exactly how browserify-cache-api works, but I'm guessing it loads the cache at start time, and writes it at the end, which means that perhaps the cache is still getting clobbered by concurrent access and lack of atomic operations?