Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using the programmatic API of browserify #13

Open
zkochan opened this issue Oct 24, 2016 · 3 comments
Open

Using the programmatic API of browserify #13

zkochan opened this issue Oct 24, 2016 · 3 comments

Comments

@zkochan
Copy link

zkochan commented Oct 24, 2016

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?

@JamesMessinger
Copy link
Member

JamesMessinger commented Oct 24, 2016

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...

@zkochan
Copy link
Author

zkochan commented Oct 24, 2016

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

@JamesMessinger
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants