Watch multiple destinations

[chrisjaure]

I'm trying to build bundles with dynamic mappings but it doesn't appear to be working.

For example, instead of specifying src and dest, I'm using a dynamic mapping like this:

files: [
        {
          expand: true,     // Enable dynamic expansion.
          cwd: 'lib/',      // Src matches are relative to this path.
          src: ['**/*.app.js'], // Actual pattern(s) to match.
          dest: 'build/',   // Destination path prefix.
          ext: '.min.js',   // Dest filepaths will have this extension.
          extDot: 'first'   // Extensions in filenames begin after the first dot
        }
]

This allows me to generate multiple bundles matching the src pattern. This used to work in an earlier version. Is it not supported anymore?

[chrisjaure]

Correction: it does build, but there is no output on the console. Watching, however, does not work. No changes to the files are detected so it never rebuilds the bundles.

[chrisjaure]

Looks like the issue is that the task is run once for each destination, and since I'm using the keepalive option, only the first destination is ever watched. Changes are detected appropriately for the first but not for the others. Updated the issue title to reflect this.

[duro]

I was able to solve for this using the grunt-concurrent plugin and some JS functions for building paths. I am close to having an example I can show. I will post one when it's ready.

[felipap]

I'm having the same problem, only the first destination is being watched.

[drinchev]

+1 I'm having the same problem.

[yang]

+1 I'm also having the same problem. It appears that each file will affect only one of the bundles that they appear in. I think.

[QuentinFchx]

+1 !

[maiermic]

I would appreciate a solution, too.

[AdrienGib]

+1 ...

[tleunen]

Hey @chrisjaure and @f03lipe, I'd like to take a look at this.. Do you have a test environment to share so I can start somewhere?

[chrisjaure]

@tleunen Here's a basic setup: https://gist.github.com/chrisjaure/25af865ffb6561adca22

Run grunt browserify:dist to build it and grunt browserify:watch to watch it. While watching, make a change to and save common.js and check the contents of second.min.js to see that it hasn't been updated.

Thanks for looking into this.

[tragiclifestories]

@tleunen Did you ever get anywhere with this?

[petersendidit]

If you use the example in https://github.com/jmreidy/grunt-browserify/tree/master/examples/watch and use the 'browserifyWithWatch' task browserify will correctly watch multiple bundles. Using grunt-contrib-watch as the keepAlive seems to work.

As some have noted the problem is that when you specify keepAlive: true browserify never calls the next function which would allow the next bundle to get updated. I don't see an easy way to fix this as grunt is handling the files and handing the browserify task one file at at time. Browserify never knows that there are multiple bundles. You would have to have some new task that does all the multiple bundle file handling so it knows to keep looping over the bundles.

[tleunen]

Sorry I'm quite busy these days.. I'll be more available in 2 weeks and will be able to take a look.

[tleunen]

I made a change in my fork. Could you test it a bit before I merge it in the main repo?
https://github.com/tleunen/grunt-browserify/tree/feature/multi-dest
You can use my fork by modifying your package.json file and changing the version of grunt-browserify to git://github.com/tleunen/grunt-browserify.git#feature/multi-dest
The change is really minimal but I want to be sure nothing breaks.

[chrisjaure]

@tleunen Looks like that did the trick! Thanks a bunch!

Some notes:

• The process died with a segfault once, but it looked like it was caused by watchify. Haven't been able to reproduce it again.
• Nitpick: it prints >> Watchifying bundle <name>... every time a change is detected and the bundle is updated, which gets a little noisy.
• Now that I don't have to use grunt-contrib-watch, processor usage is way down and rebundling is super quick, as expected :)

[tleunen]

Before, it was printing >> Watchifying.... I added the bundle name so it's easier to know which one is ready. What do you suggest?
I'd like to keep a comment because it tells the user that the bundle is ready.

[chrisjaure]

When a file changes, I see:

>> <file> changed, updating bundle.
>> File <bundle> created.
>> Watchifying bundle <bundle>...

Isn't it enough to show just the first two messages since it's implied the bundle is being watchified when the task is first run? But that's fine if you can't differentiate between first creation and subsequent creations. I can deal with a little extra noise :)

[tleunen]

I merged the watchifying message with the bundle created message. Is it better? :)
So it's now:

>> <file> changed, updating bundle.
>> <bundle> created. Watchifying...

[chrisjaure]

👍