You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given that the main feature of the library explicitly depends on date-fns, I wonder if there any downside to putting it as a direct dependency instead of a combination of dev+peer dependencies?
Doing so would also allow to remove the recommendation in the README to add the date-fns library explicitly to a project.
Additional observations: if someone omits the recommended step of adding date-fns as an explicit dependency, the behavior will differ depending on the package manager used: npm will install the peerDependency, while yarn will not, resulting in a broken build.
To sum up, I would like to know if there is any history behind not putting date-fns as a direct dependency, and if not, are you open to doing otherwise?
The text was updated successfully, but these errors were encountered:
Given that the main feature of the library explicitly depends on
date-fns
, I wonder if there any downside to putting it as a direct dependency instead of a combination of dev+peer dependencies?Doing so would also allow to remove the recommendation in the README to add the
date-fns
library explicitly to a project.Additional observations: if someone omits the recommended step of adding
date-fns
as an explicit dependency, the behavior will differ depending on the package manager used:npm
will install thepeerDependency
, whileyarn
will not, resulting in a broken build.To sum up, I would like to know if there is any history behind not putting
date-fns
as a direct dependency, and if not, are you open to doing otherwise?The text was updated successfully, but these errors were encountered: