Are you of that party that thinks that every component could (and should) be defined like that?
I'm not React expert but I find it quite a stretch, because there are components that just need internal state, but it's too verbose/cumbersome/overkill to rely on Redux (or anything like that) for the case. Is there a best practice guide for that?
May I suggest not doing that? I mean, developers need a little stability. Semver is ok and all, but releasing 7 versions in two hours (incluing a minor one) makes me think it's a rushed release.
Instead, take a little more time, publish a more polished version when you're quite done. Bugs might still slip out, but it's no big deal to release a patch version shortly after.
*One* patch, though, not 6 *and* a minor upgrade.
That was expected, sadly. It's not an easy task.
In the meanwhile, Node community might opt to use another extension to tell CommonJS and ES2015 modules apart. I really hope it won't happen.
That's the problem of not having tests: you should have noticed that in Firefox vendor-prefixed style properties begin with "Moz", not "moz".
Other suggestions:
- one could pass the perfectly valid property "font-smoothing", the function would have tried searching for "webkitFont-smoothing"... and failed, because it's "webkitFontSmoothing". So, camelCase the *whole* property, or make the documentation clearer that they should use "fontSmoothing" instead;
- it doesn't check for vendor-prefixed *values*, like "-ms-grid" for display. Unfortunately checking them isn't as easy, but that would be one of the perks of such a package. As it is, it's quite trivial and similar to many others (e.g.: https://www.npmjs.com/package/prefix-property).
This seems like an over-engineered CodePen snippet than a real package.
Moreover, it has nothing to do with JavaScrpt, just HTML and CSS.
Finally, let us decide if it's awesome or not (personally I think it's pretty bland).