Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Date library dependency in v8

See original GitHub issue

DayPicker relies on some date manipulation functions to work. Until v8 I’ve been maintaining a custom set of utilities to keep the bundle size small.

I underestimated the difficulties working with dates and other abstractions required to support localization, so I decided to switch to date-fns.

This choice is raising some valid concerns in the community, which I would like to collect here.

References:

Issue Analytics

State:
Created 4 years ago
Reactions:3
Comments:15 (1 by maintainers)

Top GitHub Comments

2reactions

gpblcommented, Jan 28, 2020

I think the main issue here are localization-based calculations (eg first day of the week). I’d go with date-fns and study the problem with a lower priority. There are many options out there! I really want to push date-fns, it is good for the ecosystem.

Different approaches can be tried after the release. But i’d better discuss real use cases like yours first…

1reaction

hornetDCcommented, Oct 15, 2020

Is it possible to somehow use v8 without date-fns? We are using dayjs in our project, v7’s formatDate and parseDate props are very convenient. I don’t want to bring extra dependency.