Open zkochan opened 7 years ago
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...
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
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.
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?