Add fantasy-land 2.0 compat namespaced methods

[briancavalier]

This is not complete, but wanted to open it for discussion. Inspired by @bergus' comment here, it was trivial to add fantasy-land 2.0 compat, while maintaining back compat with current creed 1.x.

If we want to go this route, then there's a bit more todo:

• [x] Update docs
• Merge #34, then update this PR to add namespaced bifunctor
• [x] Add tests to verify fl namespace methods. Not sure the best way to do this, since we're already testing FL laws. Perhaps this is the right time to use the official fl laws test suite

[coveralls]

Coverage decreased (-0.5%) to 99.491% when pulling 04e24b87ea7054dea700191ef9e7b46095961606 on add-fl-2.0 into a006e6e1fcaedfd92bb853c6b29d0d05bbfd74cf on master.

[bergus]

LGTM.

[coveralls]

Coverage decreased (-0.8%) to 99.241% when pulling 4434b0dd2f601e9a5c8e6c9d65a46dae7ed372f4 on add-fl-2.0 into a006e6e1fcaedfd92bb853c6b29d0d05bbfd74cf on master.

[coveralls]

Coverage decreased (-0.8%) to 99.241% when pulling 4746514a70bac9f8a043b57a79cbde4e4fdf67de on add-fl-2.0 into a006e6e1fcaedfd92bb853c6b29d0d05bbfd74cf on master.

[coveralls]

Coverage decreased (-0.8%) to 99.241% when pulling 4746514a70bac9f8a043b57a79cbde4e4fdf67de on add-fl-2.0 into a006e6e1fcaedfd92bb853c6b29d0d05bbfd74cf on master.

[coveralls]

Coverage decreased (-0.8%) to 99.241% when pulling 517d451a13ec942ec1a660f2313ed2462cee28a7 on add-fl-2.0 into a006e6e1fcaedfd92bb853c6b29d0d05bbfd74cf on master.

[briancavalier]

It's not clear to me why coverage isn't 100% after 4746514, and the html coverage isn't any help :/ If you look at the diff with master, only the new namespaced methods have been added. Since they just just immediately call existing code (which was already at 100% coverage), they should be fully covered simply by calling them at least once somewhere in the test suite, which is what 4746514 does.

If you look back at this coveralls comment, which is just before 4746514, then commit where I added the laws. Then, look at this one, after that commit, the coverage percentage is exactly the same. IOW, the fantasy land laws, somehow, are simply not being counted by coveralls.

I'll try a test where I explicitly call one of the new methods in a test directly, rather than letting a fantasyland law call it, and see if that helps.

[briancavalier]

That seems to be the problem: istanbul isn't reporting code covered by the fantasy land laws. (perhaps since they are outside of the dirs being instrumented?)

Here's what local istanbul reports for me in this PR branch:

Statements   : 99.27% ( 813/819 )
Branches     : 89.96% ( 206/229 )
Functions    : 97.38% ( 223/229 )
Lines        : 99.24% ( 784/790 )

And here's what it reports for me when I use a hand-coded Functor identity test instead of delegating to fantasy-land/laws/functor.

Statements   : 99.39% ( 814/819 )
Branches     : 89.96% ( 206/229 )
Functions    : 97.82% ( 224/229 )
Lines        : 99.37% ( 785/790 )

I guess an alternative is to write our own simple set of tests for the FL namespaced methods in addition to using the FL test suite. I was hoping just to rely on the FL suite, tho.

[coveralls]

Coverage remained the same at 100.0% when pulling 45d71db90f60125803dd2011f635ff8e5a893d29 on add-fl-2.0 into a006e6e1fcaedfd92bb853c6b29d0d05bbfd74cf on master.

[briancavalier]

Haha, lovely. Fantasy Land's laws node modules require a version of node that supports destructuring. Since node 6 is LTS now, we could drop node 4 & 5.

[briancavalier]

See #87

[coveralls]

Coverage remained the same at 100.0% when pulling e393a58a918929514eff2f509f1e9eda88f0d97d on add-fl-2.0 into e2f5510f3ec80073d8c5ed6a1aa1f4977104f079 on master.

[coveralls]

Coverage remained the same at 100.0% when pulling 1eb3e8f0d1a2b67548031dd9b7f8d8b45f2f7362 on add-fl-2.0 into e2f5510f3ec80073d8c5ed6a1aa1f4977104f079 on master.

[briancavalier]

Now that FL 2.1 is released, it might be more correct to implement Alt (currently concat, i.e. race) and Plus (currently never), rather than Semigroup and Monoid. Since Monoid should probably concat the values within the promises, rather than racing.

We could still leave concat for backcompat in 1.x.

Thoughts?