Sorry 'bout that, those were only facts didn't meant to be offensive. Thing is there are many date picker implementations and I always have the feeling that those are too heavy...
I've introduced the type="date" attributes support (eg: min, max) and added format to the input attributes. This way, it can almost be a full polyfill, it'll still replace the type attribute with `text` so that the browser doesn't interfere with handled events/value.
Indeed but it's an interesting idea. Anyway, you'll have to change type=date to type=text, at least programatically to ditch the navigator behavior...
Thanks about the bundle idea, I'll think about that. Thing is, if you're handling dates with javascript, you probably already use momentjs. IMO it's easier to let the end developper bundle everything his way.
Indeed, but without dependencies it's a lot more work. Anyway, moment is great for date management so IMO it's a dependency in lots of projects dealing with dates.
About the polyfill, with dpicker:
;[].slice.call(document.querySelectorAll('input[type="date"]')).forEach((e, i) => new DPicker(e))
Not really, you've seen how many lines of code "rome" has? 2253 sloc in the standalone version, even with comments dpicker is 578 sloc, and I've lot of comments compared to rome.
Also, I count 4 dependencies, where dpicker has only 2.
I don't speak about maintenance either (38 issues, 14 PR, not updated since a year). A date picker is supposed to be simple and straightforward. Btw rome is almost not commented.
So the only difference with https://www.npmjs.com/package/npm-check-updates is that you run tests after each update? (and that you've a fancy logo ofc)
Are you handling semver like they do? I see no informations about it in the README.