merge features from virtual-hyperscript

[Matt-Esch]

I went to update virtual-dom to the latest version of virtual-hyperscript, but it depends on vtree. In my efforts to reduce this "yet another vtree dependency" problem, I have simply merged the changes from virtual-hyperscript into virtual-dom/h. cc @Raynos

[coveralls]

Coverage decreased (-7.68%) when pulling bb7f1ee on virtual-hyperscript into 8577b4f on master.

[Raynos]

@Matt-Esch

Rather then copying and pasting the source code of virtual-hyperscript in here. It might be better to just delete the h code completely.

Alternatively having another copy of vtree instead would be preferable over copy pasted code.

If you really do want to copy paste, consider using a git submodule or something.

[gsf]

Copying and pasting? Submodules? Ugh.

If h is only used for the tests, then virtual-hyperscript should be a devDependency of virtual-dom. If virtual-dom, virtual-hyperscript, and vdom all need to rely on the same instance of vtree, then all three should have vtree as a peerDependency.

[gsf]

...and I'm catching up with the last year of hate on peerDependencies (npm/npm#5080). If we're tempted in that direction is that a sign that we could be handling things better? Do virtual-dom, virtual-hyperscript, and vdom (and mercury) all need to depend on vtree, or could these dependencies just be at the API level (akin to Mikeal's suggestion)?

[Raynos]

@gsf peer dependencies are the wrong thing.

There are complex dependencies on the data structures in vtree.

We just have to manage the versions and not fuck it up. That's what we get for having complicated data structures.

Also the fact that there are tests in virtual-dom instead of there being tests in vdom and vtree is weird. If we need h for tests we should just delete the tests and move them to vtree and vdom.

[gsf]

@Raynos Agreed on all points (especially moving tests out of virtual-dom).

[Matt-Esch]

If you take mikeals suggestion, I would go around turning all of the things that depend on vtree or vdom into interfaces that allow you to initialize that dependency with a version of vtree/vdom. Note that in this case, vdom becomes module.exports = function(vtree), as does virtual-hyperscript. vdom should probably also expose the vtree things because having function(vdom, vtree) introduces yet another point of inconsistency.

I was intending for virtual-dom to be a consistent easy to use export. The MVP without causing version suffering. The tests in virtual-dom are integration tests, proving that these modules work together at these versions. The vdom and vtree modules should have separate unit tests. Technically, given the "inverted dependency" vdom has on vtree, I should be mocking the vtree dependency in the vdom tests. It's a mess, I'm open to suggestions that don't come with the caveat of version hell. Clearly what we are doing right now is bad.

We just have to manage the versions and not fuck it up.

^ This is bs. "We" becomes everyone who uses these modules.

[Raynos]

That is not mikeals suggestion. You depend on interfaces not functions.

Since one of the advantages of seperate modules is less KBs in the browser, we can achieve this by just having the virtual-dom package expose multiple modules.

The current situation is bad, might as well move them all back into virtual-dom.

[Matt-Esch]

Well, looks like we moved everything. Also @Raynos what you depend on and how you depend on it are 2 different things. It seems Mikeal is suggesting that you depend on an interface, and the concrete implementation is supplied to that depending module instead of it providing for itself via require.