Build 'dest' filename as a substring of an 'src' target triggers infinite rebundle

[tcharlat]

I have this issue with grunt-browserify, but I guess the watchify watcher is the cause of this issue.

options: {
  watch: true,
  cache: true,
  keepAlive: true
},
files: {
  '.tmp/scripts/target.js': ['.tmp/scripts/app.jsx']
}

Is fully functionnal.

options: {
  watch: true,
  cache: true,
  keepAlive: true
},
files: {
  '.tmp/scripts/app.js': ['.tmp/scripts/app.jsx']
}

This configuration re bundles infinitely, when 'app.js' is re-written, it triggers a new rebuild.

D:\Workspace\showcase>grunt browserify:testreload
Running "browserify:testreload" (browserify) task
>> Bundle .tmp/scripts/app.js created. Watchifying...
>> D:\Workspace\showcase\.tmp\scripts\app.jsx changed, updating bundle.
>> Bundle .tmp/scripts/app.js created. Watchifying...
>> D:\Workspace\showcase\.tmp\scripts\app.jsx changed, updating bundle.
>> Bundle .tmp/scripts/app.js created. Watchifying...

I guess the watcher can't discriminate 'app.jsx' and 'app.js'. I started digging into the source and it seems the watch event might be triggered by the chokidar dependency, in that case I guess the issue is irrelevant.

PS :

• my system is win 10
• node is v4.2.1
• modules are up to date

[zertosh]

Can you provide a repro case without grunt-browserify?

[tcharlat]

Yes and it confirms the issue :

> watchify app/scripts/react/app.jsx -o app/scripts/react/app.js -t [babelify --presets [es2015 react] ] -v

5159 bytes written to app/scripts/react/app.js (2.82 seconds)
5159 bytes written to app/scripts/react/app.js (0.05 seconds)
5159 bytes written to app/scripts/react/app.js (0.07 seconds)

etc.

PS:

• watchify v3.6.1
• browserify v12.0.1

[tcharlat]

As a matter of fact, I finally avoided the output in the source folder. It's not a good practice and didn't help (at all).

I was actually trying to hack my way out of useminPrepare, which has trouble targeting outside of the canonical source folder. And somehow ended up testing some things which led me to this bug.

I sanitized my source and output management and I don't target jsx anymore with usemin. Still hacky, but in the end it's fine and I shouldn't have had the current issue in the first place.

Except if you feel like watchify shouldn't behave this way, it's safe to close for me.

[zertosh]

I still don't understand your issue. Can you show me a repo with a minimal case that has the problem?

[tcharlat]

@zertosh done, https://github.com/Kallikrein/watchify-issue

[zertosh]

@Kallikrein, it works for me as expected using ./node_modules/.bin/watchify ./app.jsx -o ./app.js -t [ babelify --presets [ es2015 react ] ] -v. I'm on a Mac, I'm guessing you're on windows (from your original post output)?

[tcharlat]

Yes, and I can't reproduce the issue on my server either.

I think etiher chokidar itself, or how watchify is passing arguments to it is the problem.

As I said, I don't have this bug anymore since I changed my folder structure, and shouldn't have had an output in the same folder as the sources in the first place anyway.

Unless you really want to fix this (and if chokidar is involved, you might not be able to), I would say it's safe to close this issue.

[zertosh]

Yeah, this is too much of an edge case. Thanks for reporting!

[tcharlat]

And thanks to you for checking it out !