jsdf / browserify-incremental

incremental rebuild for browserify
175 stars 13 forks source link

Problem with changing dependencies versions #14

Closed fiatjaf closed 8 years ago

fiatjaf commented 9 years ago

I can't reproduce (and I couldn't understand the generated source also), but apparently there is an issue with dependencies that change versions and/or deleted dependencies. Maybe browserify-incremental keeps using the same old versions. Is it possible that this is happening?

jsdf commented 9 years ago

Not sure I fully understand what you're asking? Basically the way browserify-incremental works is that if a file's mtime has not changed, then the cached version will be used, otherwise it will be rebuilt.

If you switch versions of a dependency (eg. by npm install) then the dependency's files mtimes should have changed, causing the cached version to be invalidated.

ianthehenry commented 9 years ago

@jsdf I think the original reporter meant "file you're requiring" by "dependency." If so, I've been bitten by this, and have a repro:

$ npm install browserify && npm install browserify-incremental
$ echo "require('./b.js')" > a.js
$ echo "console.log('hi')" > b.js
$ node_modules/.bin/browserifyinc a.js -o app.js
$ node_modules/.bin/browserifyinc a.js -o app.js
$ rm b.js
$ node_modules/.bin/browserifyinc a.js -o app.js

So the first build succeeds, as expected, and everything's fine. Then you have to build again, because of a separate bug: https://github.com/jsdf/browserify-incremental/issues/8.

Then the third build should fail, as we've deleted the b dependency, but it actually succeeds, with browserify-incremental using the cached version of a now-deleted file.

In practice this shows up for us (fortunately) as build failures on Travis when the tests work fine locally, but it's still annoying to track down.

asazernik commented 8 years ago

@jsdf mtimes will not work for NPM packages; NPM sets the mtime of files based on the time at which the package was created, not the time at which the files were updated on the local system.

For example, I have react-bootstrap 0.25.2 fetched locally. I fetched this package on 20 October, but the version was released on 12 September. Directories have mtimes of 20 October, but all the JS files involved have mtimes of 12 September.

Macil commented 8 years ago

I think there's two issues being discussed here, so I've split it out into https://github.com/jsdf/browserify-incremental/issues/35 and https://github.com/jsdf/browserify-incremental/issues/36 with separate reproduction cases.

fiatjaf commented 8 years ago

Well, if I remember well I'm still being bitten by this issue, but only when I am using a linked dependency (via npm link) and I change the files in this dependency. It is just a symlinked directory, so maybe it could be solved, but in the meantime I'm successfully remembering to manually delete browserify-cache.json whenever I change a dependency like this.