globify Using the programmatic API of browserify

Is there any reason you don't use the programmatic API of browserify/watchify

Spawning a new process for every entry point seems slow to me.

Would you accept a PR that would leverage the programmatic API of the tools?

Oct 24 '16 08:10 zkochan

Thanks for opening this issue. There are a couple reasons why I chose to use process-spawning rather than the browserify/watchify APIs.

1. Ease of debugging You shouldn't ever have to wonder whether a bug in your build step is being caused by globify. All it does is run the same browserify/watchify commands that you would normally run yourself. In fact, it even writes each command to the console, so you can see exactly what it's doing. Essentially, globify is a simple task runner; nothing more, which limits the possibility of it introducing bugs or unknowns into the build step.

2. Support for any plugin/transform/etc. Browserify & watchify have a ton of different plugins, transforms, etc, and each of them has their own API with their own quirks. There's no way I could support all of them. But by using the CLI rather than the API, I can simply modify the parts of the string that I know are globs, and leave the rest of the string untouched. I don't need to know anything about the syntax or settings of any specific plugin.

So that's my reasoning. Please let me know what you think...

Oct 24 '16 12:10 JamesMessinger

yes, it makes sense to me... but I wonder whether it would be faster with a single thread. When I tried it to bundle approximately 50 files, it worked pretty slowly

Oct 24 '16 13:10 zkochan

50 files?!? wow! You're definitely using it at a larger scale than I ever have. Most of my projects have ~10 files or less.

If you find any ways to improve performance, I'd be glad to see them.

Oct 24 '16 13:10 JamesMessinger