Merge xxx-browserify or not? about node-libs-browser

[quantuminformation]

Can you pipe webpack to testling instead of browserify?

[defunctzombie]

@substack @Raynos @dominictarr Thoughts on the above? We could test all of them under one roof and provide a nice testling badge. I think right now the testing for the core shims is rather minimal in many places.

[Raynos]

@shtylman I vote reverse. Explode this entire repo into one repo per buildin module.

[defunctzombie]

On Feb 25, 2013, at 1:41 PM, Raynos [email protected] wrote:

@shtylman I vote reverse. Explode this entire repo into one repo per buildin module.

Ok, and leave the testing for each module? There will be a lot of duplicated effort to have each module tested in testling. Also, ideally, would want one place where I can go and see. Ok core shims are all passing tests for these browsers.

Is there an advantage for multiple modules in this case?

—
Reply to this email directly or view it on GitHub.

[Raynos]

@shtylman there won't be that much duplicated effort.

You just write n unit tests for all the modules.

You have a valid point that you may want to see aggregate test results but that's easy. Make a new repo and have it no code, one test that does require('x-browserify/test/index.js') for each one and have testling create a single badge for it.

The advantage to multiple modules is "holy fuck. why are there 20 files and 1000s of lines of code in one repo"

[sokra]

hmm... a repo with n require('x-browserify/test/index.js') isn't really pretty and make testing more complicated.

Unit tests for each module may be more pain because of (circular) dependencies between modules.

Another point pro merging is that the modules can share common code so the overall size would be smaller...

[Raynos]

sharing common code is trivial with npm, it's called making new modules.

A repo that requires all the tests is only for the purpose of generating a single testling badge. You would develop and test each buildin yourself.

[sokra]

Do I have to push to the aggregated repo if I want the badge to be updated? If yes, could I push to a x-browserify repo without the badge being updated? That would be annoying...

[dominictarr]

@sokra there is hardly ever any problem with circular deps in npm/node, you'd have to really go out of your way to get that problem.

here is a crazy idea: just get the tests from core to work.
(may require a monkey patch to assert that will make it log TAP)

[defunctzombie]

@sokra Lets start with bringing things together and adding some tests. Once things stabilize we can split off anything that seems worthwhile to do so. Having everything here is perfectly fine since a user of this module has the goal of shimming node libs. All the node libs.

If you want more tests the easiest thing to do is add tests to each of the modules, one-by-one.
If you want to aggregate the test output, just put all the badges into a markdown file someplace and link to each of the modules individually. Merging modules is the opposite direction of what you want. When modules are big and complicated, it's much harder to iterate, it's much harder for outsiders to contribute, and the versions of all the functionality must be updated in lock-step with each other. For more elaboration on this point see mkdirp/issues/15.

[Raynos]

👍

[dominictarr]

think you meant this issue 17 https://github.com/substack/node-mkdirp/issues/17