Make date-fns a regular dependency

[benasher44]

It seems odd that date-fns is a peer depedency, but the library has functionality that would crash at runtime if date-fns isn't installed (locales). Can this be promoted to a regular dependency?

[gpbl]

@benasher44 thanks for your idea!

I'm not sure what do you mean - being date-fns a peer dependency means it will be installed if not already present. How do you get the crash?

[gpbl]

wouldn't it be better to ensure it's always installed, rather than ask users to install it on the side?

No, we do provide instructions for installing this package. I really want it as peer dependency :)

But since you are proposing the change, what are the benefits from changing it to a regular dependency?

[benasher44]

As a consumer, I can install just this library without worrying about the dependencies it requires. They'll get installed automatically. The side-benefit of that is I get one fewer dependency to declare in my package.json, which I'm not actually using anywhere in my code

[gpbl]

@benasher44 you are making good points here.

The change could land into the next release candidate - we could gather some feedback from other devs.

Would you open a PR with date-fns moved to dependencies in package.json? Otherwise I'll do it in one of the next days...

Thanks for your suggestion.

[benasher44]

Sure! And just want to add that I think a good way to think about peer dependencies is "would somebody always use this package with dependency X?" react-* libraries should almost always have react as a peer dependency. The point of such libraries is to use them in a react-based project. In this example, react-day-picker isn't going to necessarily always be used in a project that uses date-fns. In other words, there is no "plugin" relationship with date-fns (not like this library is part of the date-fns ecosystem, nor is date-fns a part of the react-day-picker ecosystem). I hope that makes sense!

[gpbl]

@benasher44 it does. I believe my choice came from the age without tree-shaking, and having multiple dependencies with the same version may break the world. I hope it's not anymore the case and that the increased bundle size doesn't worry other users...

[gpbl]

Implemented in #2249.