Closed ianthehenry closed 8 years ago
Cheers, sounds like it might be a race between cache loading and bundling or something... I'll look into it when I have time
I can consistently reproduce this. It never works the first time for me. I notice the cache file after the first run has an empty mtimes
object (if brfs is used, then mtimes contains only the files that were included via fs.readFileSync
). After the second run, the mtimes
object is correctly populated and future browserifyinc runs are faster.
+1, same thing happening here. But it seems to at least work fine after second run.
Here is how I'm using it in Gulp:
var bundleOpts = { debug: true, paths: ['./app/frontend/scripts'], cacheFile: 'browserifyCache.json'}
var bundler = browserifyInc('app/frontend/scripts/app.js', bundleOpts)
bundler.transform(babelify)
bundler.transform(envify)
gulp.task('bundle', function () {
return bundler.bundle()
.pipe(plumber(plumber({ errorHandler: notify.onError('Error <%= error.message %>') })))
.pipe(source('bundle.js'))
.pipe(gulp.dest('build/frontend/scripts'))
.pipe(browserSync.stream())
})
I'm have "browserify-incremental": "^3.0.1"
and "browserify": "^11.0.1",
in my package.json
+1 After building twice it works perfectly! My setup is almost identical to @andrewhamon . The versions I'm using are exactly the same.
I'm seeing the mtimes empty the first time as well.
"packages":{},"mtimes":{},"filesPackagePaths":{},"dependentFiles":{}
This is a weird thing I'm seeing: if I run
browserifyinc
, pointing it at a cache file that doesn't exist, my build takes 28 seconds (and it creates the cache file), So far, expected.But if I re-run it, it takes 28 seconds again. Only on the third run does it pick up the cache file, and I get the nice 2.25 second built time that I want.
This isn't really a problem, since I haven't seen a reason (apart from testing) to blow out my cache, but it's... odd.