Rebuild does not happen ever

[franleplant]

Hi! I've used watchify several times without problems, but right now it's not working for me. This is the command I'm running:

watchify -v -t babelify js/index.js -o js/bundle.js

This are my specs:

• OS X Yosemite 64 bit
• Zsh
• Watchify 3.1.0

Any ideas how to solve this?

Thanks! Fran

[mattdesl]

Working for me. My specs:

• OSX yosemite (10.10.1) with regular terminal
• watchify 3.1.1
• babelify 6.0.2
• npm 2.8.2
• node 0.10.32

It could be you are running an old version of watchify (e.g. global install), or maybe something to do with the babel transform.

I would do this:

npm install watchify babelify --save-dev

And add a scripts to your package.json; this will run the local version:

"scripts": {
    "watch": "watchify -v -t babelify js/index.js -o js/bundle.js"
}

Now npm run watch and see what happens. This will help rule out a few things. :smile:

[franleplant]

@mattdesl your suggestion did not work. I was already working with and without npm. I've done some additional steps nevertheless.

• Update npm, now my version is 2.7.2
• Checked my node version: 0.12.2
• Babelify version 6.0.2

Another clue is that Im using Vim to edit files, I suppose that is not relevant at all but I state it nevertheless.

Perhaps the problem is fsevents. Also, I might need to restart my computer, but it's impossible right now :smile:

Thanks a lot for your help.

Fran

[franleplant]

Just for the sake of removing obvious things I've tried:

• Running the npm task as sudo
• Changing the source files permissions: sudo chmod -R 777 .

I didnt work

[rashkov]

I am having issues with Vim as well. It actually does run the first few times that I save, and then it stops watching whatever file I'm working with. I think this has to do with how Vim saves. I think it does a "safe write" which fully replaces the file at once.

[zertosh]

@rashkov I saw your vim issue, I'll look into it. @franleplant Are you also using vim? If not, what editor?

[franleplant]

Im also using vim! I tried with Sublime Text 3 with no differences.

[rashkov]

Sublime text doesn't have this problem for me, and emacs either. Only Vim gives me trouble. So we are probably looking at two different issues.

[franleplant]

@rashkov what OS are you using?

(It seems that we are experiencing different issues yes)

[rashkov]

I'm using Linux. You mentioned earlier that maybe it's an fsevents issue. From what I understand, watchify uses chokidar to watch for file changes, and chokidar uses fsevents to make that work on OS X systems. You might want to try to npm install chokidar and then run something like this, and then try saving your file to see if it picks up on that change. Make sure to change "./a.js" to the file that you're editing, of course.

var chokidar = require('chokidar');

chokidar.watch('./a.js').on('change', function(){
  console.log('changed');
});

[TylerK]

I'm also having the same issue as @franleplant

• OSX 10.10.3
• Node 0.12.2
• NPM 2.7.5
• Watchify 3.1.1
• SublimeText 3

When files are saved they're successfully kicking off my linters and other watch processes, but not Watchify.

[franleplant]

@rashkov run the test that you suggested and editing a.js file with vim triggers the change event.

[zertosh]

I spent the day fixing other thing so I haven't had a chance to test out what I'm about to suggest:

w.r.t. the editor and the change event: If your editor isn't doing an "edit" but rather an "alternate-save-then-rename" (vim's swap file, or sublime's "atomic_save"), then I'm not entirely sure that chokidar fires a "change" event. maybe that's considered an "unlink" followed by an "add"?

w.r.t. fsevents, have you tried watchify's "poll" option? that switches chokidar into polling mode, which IIUC does not use fsevents.

w.r.t. other watchers working, https://github.com/substack/watchify/issues/201#issuecomment-93766476 might offer some clues.

[DavidStrada]

I don't know if I was having the same problem but i solve mine by replacing -o and use instead --outfile ( pasted my config below ).

watchify app/app.js -t babelify --outfile bundle.js --debug --verbose

[franleplant]

@zertosh , look at the test that suggested @rashkov that basically rules out that the problem is that vim or sublime are not triggering the chokidar update event.

Also, I tried --poll and it does work with it.

Also tried this watchify -t babelify js/index.js --outfile js/bundle.js --debug --verbose as suggested by @DavidStrada and didnt work.

[Dudemullet]

Can verify that same as @franleplant. When I use --poll=true other files required in my bundle entry point are listened to, other than that, only changes to the entry point are triggering a rebuild.

• OSX 10.10.3
• ZSH
• Vim 7.4

[TylerLH]

FWIW, I'm not getting rebuilds using any of these suggestions. I've tried to get this working using command line, npm, as well as gulp tasks -- all with no luck.

• OSX 10.10.3
• ZSH
• Sublime 3 (Have also tried vim)

[asinner]

This has been an issue for me as well. Watchify runs the first time and waits, however it does not rebuild after a file has changed.

• OSX 10.10.2
• Sublime, Textmate, Atom
• Watchify v3.1.2
• Browserify v9.0.8
• Node v0.10.32
• NPM v2.7.0
• Reactify v1.1.0
• 6to5ify v4.1.1

Tried it with::

 watchify -t 6to5ify ./src/entry.jsx -o./dist/bundle.js -v

And also with:

 watchify -t reactify ./src/entry.jsx -o./dist/bundle.js -v

The --output command did not work for me either.

[zertosh]

@franleplant Since polling worked for you, I'm going to chuck this one to something unique about your setup and/or chokidar. If you happen to figure out the cause and it's addressable via a PR, I'd really appreciate it.

---

@rashkov I'm super puzzled by your issue. I didn't see a comment as to whether polling worked for you or not. Can you check?

---

@TylerK and @asinner: Please open new issues with specifics on your particular setup and use.

[franleplant]

@zertosh I agree, the problem is fixed for me, but the situation could be much better if we could just use watchify without the poll.

Is there some tests I can run? For example attempting to run Watchify's own test suites on my system?

Fran

[zertosh]

@franleplant Sure, the tests are pretty good. Are you by any chance watching files across NFS? I added polling because users who where running containers could only watch with polling.

[franleplant]

@zertosh nope, no containers or VMs.

I cloned, installed watchify and then run the tests:

1..98
# tests 98
# pass  98

# ok

So, the tests are working in my system, perhaps there is not a test case that covers my particular case? I didn't read the tests, but this seems like the main thing to test in watchify, so Ill assume that this is covered.

I have the same problem with watching file with nodemon, is there something that both have in common? Also, I replaced nodemon with chokidar-cli and file listening works like a charm.

Fran

[zertosh]

@franleplant Yup pretty much every test relies on the watcher correctly firing an update event. I think nodemon uses fs.watch, but it seems to try a lot of different approaches.

The nodemon bit is strange. I'm on OS X 10.10.3 (bash 4.3.33(1)-release - not that I think it matters) and I normally edit with Sublime Text 3 (not that I think it matters either). My most watcher heavy projects run from gulp, and they involve watchify, multiple gulp.watch (for css and templates), and nodemon (for a server).

[franleplant]

Yes, I agree this all seems strange, let me know if you find out anything.

Thanks a lot for your support.

[rashkov]

@zertosh --poll helps, although it will still occasionally miss a 'change' event and not trigger the rebuild. However it doesn't just stop watching the file like it would without --poll.

[Dudemullet]

FWIW, I ran a test using watchify on a simple project. (2 files, 1 requires the other, no polling) and everything seems to be working fine. But when I use it on a complex project (20+ source files, nested directories 3+ levels) thats when I stopped working without the poll.

I'll try and come up with a more specific example so we can narrow it down.

[zertosh]

@franleplant Np.

@rashkov Grrr, that's weird.

@Dudemullet Yes please, if you can come up with something I can test locally, that'd be awesome. wrt a complex project, I've got wayyyy bigger builds than that - with devs on different machines and envs. BUT, we do have shallow dir structures - 3 levels max. I have to run an experiment with something deeper.

[jatcwang]

I'm running into this issue on Arch.

I'm using Gulp as the task runner, and after about 20 seconds. Gulp say Finished 'watch' after 16 s where watch is my setup for watchify.

Here are my relevant configurations in gulpfile.js

gulp.task('watch', function() {
  var opts = _.assign({}, watchify.args, {poll: true});
  var bundler = watchify(browserify('./js/main.js', opts));
  bundler.transform(babelify);
  bundler.on('update', rebundle);

  function rebundle() {
    return bundler.bundle()
      // log errors if they happen
      .on('error', gutil.log.bind(gutil, 'Browserify Error'))
      .pipe(source('bundle.js'))
      .pipe(gulp.dest('./dist'))
      .pipe(reload({stream: true}));
  }

  return rebundle();
});

For polling, I tried poll: true as well as poll: 300 but neither seem to help.

gulp@3.8.11 watchify@3.1.2 browserify@9.0.8

This issue started happening after I upgraded my various dev dependencies.

[franleplant]

@jtcwang you should try to run watchify via the CLI.

[zertosh]

@jtcwang I don't think your issue is what's being talked about in this thread. Your issue doesn't seem to be related to watchify since your problem is with the length of the initial build. Please open a new issue with a bit more detail.

[benmosher]

FWIW: I've seen this issue with chokidar on OS X due to the fsevents getting hosed for a given folder. Many people on my team routinely have to either move their working directory to a folder that hasn't been trashed, or use one of the techniques here to "repair" the broken folder.

An easy test to see if fsevents is a likely culprit: open Finder in your working directory (where your JS is), and then touch a new file in that folder from a terminal. If you don't see the touch'd file in Finder immediately, fsevents may be hosed for that folder, or one of its ancestors.

(a few of my teammates had it broken for the entire /Users folder, and had to move the working directory to a /Dev folder to get events working again)

[franleplant]

@benmosher I've done the touch ing and checking on Finder and the changes are reflected immediately.

Nevertheless I did mv 'd my project folder to a different name and then mv 'd back to its original name and watchify started working without the --poll flag.

This is a really annoying bug in OS X's file system!

@zertosh so this is a far as we can get towards resolving my original problem, maybe creating some notes in the watchify docs about this?

[zertosh]

@zertosh so this is a far as we can get towards resolving my original problem, maybe creating some notes in the watchify docs about this?

@franleplant PR welcomed :)

[Dudemullet]

I know this is farfetched but, have you all updated to the latest version? Has not happened to me since. Thats why I haven't been able to reproduce a proper to test

[franleplant]

@zertosh done! Not sure about the doc styling so let me know if you want to present this info in some other way.