Watchify not rebuilding

[TylerK]

@zertosh As per your direction, here is a new issue with my specs:

• OSX: 10.10.3
• Node: 0.12.2
• NPM: 2.7.5
• Gulp: 3.8.11 (both CLI and local)
• Browserify: 9.0.8
• Watchify: 3.2.0

And here is my gulp bundle logic:

gulp.task('bundle:dev', function () {
  const projectBundler = function (_bundle) {

    const args = {
      entries         : _bundle.src
      , debug         : true
      , cache         : {}
      , packageCache  : {}
      , fullPaths     : true
    }

    const bundler = watchify(browserify(args).transform(babel, { global: true }))

    const rebundle = function () {

      const start = Date.now()
      util.log(util.colors.cyan('Building ->', util.colors.white(_bundle.name)))

      return bundler
        .bundle()
        .on('error', function (error) {
          ErrorHandler(error)
          this.emit('end')
        })
        .pipe(source(_bundle.outputName))
        .pipe(gulp.dest(_bundle.dest))
        .pipe(reload({ stream: true }))
        .pipe(notify(function () {
          util.log(util.colors.cyan('Finished ->', util.colors.white(_bundle.name), 'in ->', util.colors.white((Date.now() - start) + 'ms')))
        }))
    }

    bundler.on('update', rebundle)
    return rebundle()
  }

  config.bundles.forEach(function (bundle) {
    projectBundler(bundle)
  })
})

Let me know if you need any additional info! Much appreciated any attention you can give this problem as it's fairly blocking. :)

[TylerK]

Follow up: All of Watchify's tests passed

1..98
# tests 98
# pass  98

Problem still persists, however.

[zertosh]

Nothing jumps out at me from your code. Applying a transform like babel (you mean babelify?) globally is really expensive, but that doesn't affect a rebuilds ability to kick-off. Did you try poll: true?

[TylerLH]

Is your project in your Dropbox (or similar) folder? I was having the same issue until I realized that was the culprit and moved the project into my regular FS.

[TylerK]

@TylerLH Negative, the projects are not in a Dropbox or Google Drive folder.

Oddly enough, my work computer has the same project and specs as listed above and Watchify runs beautifully.

[TylerK]

@zertosh Yep, it is actually Babelify. The global is there due to some folders being symlinked in to node_modules for convenient requiring :)

[zertosh]

@TylerK so the exact same project works in one machine but not another? O_O I wonder if it's the symlinks

[jmm]

@TylerK If you want to avoid the global transform you can try my pathmodify plugin (although I haven't tried it will fullPaths -- don't know if that will make any difference). It'll allow you to use module style require() paths, with or without the files being symlinked in node_modules, and apply programmatic transforms. Basic usage (assuming calls like require('app/whatever') and with or without a symlink at node_modules/app) would look like:

var pathmod = require('pathmodify');
args.entries = [/* paths outside of node_modules */];
watchify(browserify(args)
  .plugin(pathmod(), {mods: [
    pathmod.mod.dir('app', '/path/to/dir-outside-of-node_modules')
  ]})
  .transform(babel)
)

[TylerK]

@zertosh Same symlinks too ;)

I'm going to chalk this up as ghost-in-the-machine for now. I'll keep hammering at this and report back any findings.

@jmm This looks pretty cool, I'm going to give it a shot. Thank you

[jmm]

@TylerK thanks. If you have any questions or feedback please open an issue on its repo.

[alexahn]

• OSX 10.10.2
• Node 0.12.2
• NPM 2.7.4

I'm having the same issue with the latest version of watchify, and I've been doing some debugging. In my particular case, it seems that chokadir is not properly working with fse, and I believe it is related to this:

fsevents/fsevents#63

[ngasull]

• node 0.10.38
• npm 1.4.28
• watchify 3.2.1

Same issue here on Ubuntu linux. Please note that since I've downgraded to watchify 3.1.2, I have no more rebuild issue.

update event is triggered well, but the bundle action that follows does not output anything.

[JonathanBruce]

I have a similar issue? I don't believe the problems are the same.

using

• babelify: 6.0.2
• browserify: 10.1.1
• watchify: 3.2.1
• reactify: ^1.1.0

Each rebuild unless I restarted my gulp tasks would be the same as the original startup build. I examined the cache for my index.jsx file and deleted it explicitly

 bundler._options.cache = {};

only then do the changes get rebuilt and added to my dist directory.

[tptee]

Ran into similar issues on OSX 10.10.4 with the following versions:

iojs: 2.0.1
babelify: 6.1.1
browserify: 10.2.0
watchify: 3.2.1

Watchify triggers sporadically or not at all per gulp session. A workaround (opts.poll) is in this issue: fsevents/fsevents#63

[lpdumas]

Had the same issue. @tptee workaround did it for me (the poll opts) ;)

const bundler = watchify(browserify(args).transform(babel, { global: true }), { poll: true })

[JonathanBruce]

awesome that worked for me thanks.

[burdiyan]

Didn't work for me. Not rebuilding on update.

var gulp = require('gulp'),
    browserify = require('browserify'),
    watchify = require('watchify'),
    source = require('vinyl-source-stream');

var opts = {
    cache: {},
    packageCache: {},
    debug: true,
    entries: './test.js'
};

var b = browserify(opts);
b = watchify(b, {poll: true});
b.on('update', bundle);

function bundle() {
    return b.bundle()
        .pipe(source('bundle.js'))
        .pipe(gulp.dest('./'));
}

gulp.task('build', bundle);

UPD Looks like it was working. But when watchify do rebundle, the gulp task is not triggered, so there is no output. I have added the following to see the output from watchify:

b.on('log', function(data) {
    console.log(data);
});

[YourDeveloperFriend]

I'm running into this issue too, and I was able to get it to work by manually removing the cache on update:

bundle.on('update', function(filename) {
  delete bundle._options.cache[filename];
  bundle.bundle()
  // gulp stuff
  .pipe(source('app.js'))
  .pipe(gulp.dest('public/js'));
});

[royriojas]

I have this issue and find it happens intermittently. Some times it works and sometimes it doesn't. It happens more often in Linux environments. Weird thing, using watchify@2.6.0 works as charm everytime and everywhere...

[royriojas]

I was able to get an scenario where the issue always happen. Basically it goes like this in my case.

• If you run watchify@3.2.3 from an spawned process the issue happens intermittently, but it will happen pretty consistently for some files.
• If run it directly it will work normally and not fail.

If you run the same using watchify@2.6.0 and repeat the experiments above, it works normally.

[royriojas]

So the issue is inside the chokidar module. If you use chokidar@0.12.6 no issues at all. Using chokidar@latest. Issues happen pretty consistently. I guess this should be reported as a bug on their side then

[zertosh]

@royriojas Interesting. So the main difference between 2.6.x and 3.0.0 is chokidar. Can you open a new issue to discuss this?

[royriojas]

Sure thing! @zertosh

[royriojas]

so actually @zertosh the issue is not really in chokidar I manage to find the difference between 2.6.0 and 3.2.3 in this function

function collect () {
        b.pipeline.get('deps').push(through.obj(function(row, enc, next) {
            var file = row.expose ? b._expose[row.id] : row.file;
            cache[file] = {
                source: row.source,
                deps: xtend({}, row.deps)
            };
            watchFile(row.file); // this is missing in 3.2.3 Adding it works again in my case. 
            this.push(row);
            next()
        }));
    }

I'm currently working on a solution that persist the cache to disk, so this will speed up builds even in no watch mode. So in my use case the initial cache object does contain info, it seems that is preventing the file event from being fired from browserify. watchify@2.6.0 does set the watchers during the collect phase and that explains why it worked for me before and does not with the latest one.

[zertosh]

@royriojas That watch call was unnecessary. I've experimented with a file cache myself - If you open a new issue with the code you're using, we can come up with something that works for you.

[royriojas]

Thanks @zertosh, will do it and prepare an small repo where that can be reproduced.

[royriojas]

@zertosh I have created #240 with a link to a repo that can be used to replicate the issue.

[rashkov]

Using Linux here. Not sure if this is still the same issue, but I'm finding that even with polling turned on it'll still skip some rebuilds. This issue is much worse on my spinning disk machine than my ssd machine, although it still happens for both. Setting Vim's noswapfile option seems to fix this. Maybe there's some kind of race condition going on? Seems to be sensitive to latency.

[MrMMorris]

hi all. Not sure if I am having the same issue that is relevant to this ticket.

watchify 3.0.0 with poll: true over NFS only runs the initial build and then fails to pick up any subsequent file changes.

[ghost]

I've been getting this issue sporadically on linux for a while too. One thing I've noticed is that only certain files seem to be affected. Once a file "goes bad" it will fail to rebuild that file on a change, but other files will trigger a rebuild.

[ghost]

Issue replicated, pull request sent for review.

[MrMMorris]

@substack thanks for the PR! It looks like I may be having an issue similar to yours as I have found some files what work. Look forward to this being fixed!

[parshap]

I'm still getting the issue where a certain file "goes bad" and subsequent changes to that file fail to get recognized until I restart the process. Changes to other files will continue to work fine. Using watchify@3.3.1 and browserify@11.0.1 on Ubuntu.

[MrMMorris]

yea, I am using 3.3.1 as well and it seems that only a couple files don't trigger a build. Restarting/recreating process doesn't help.

[zertosh]

I'm locking this thread because it's gotten too noisy. If you're having rebuild problems please open a new issue with details about your setup and some way to reproduce. I'd really like to help but if I can't reproduce it, then I can't debug it.