react-datepicker
react-datepicker copied to clipboard
Hacker0x01
Upgrade to `date-fns` version 3
There are some mild breaking changes in date-fns version 3, particularly around imports. Codebases that use date-fns and react-datepicker are blocked from upgrading date-fns until react-datepicker updates this dependency.
I could use some help to upgrade this in our package. I'm preparing a major upgrade with some breaking changes and could include this as well ideally.
Tried to get the project running so I could look at contributing however encountered an issue getting the project to build (something about command 'tee' not found).
When I migrated some of my own code it was just a case of updating the format of the import statements which I was able to do with a regex find and replace.
e.g.
import parse from "date-fns/parse"; -> import {parse} from "date-fns/parse";
I have also found a few places where there are imports from the root of date-fns, these need replacing
import { isSunday } from "date-fns" -> import { isSunday } from "date-fns/isSunday "
I will have another go at getting the project running next week.
Awesome, sounds good. I'll be here to review the PR once you have it ready.
Tried to get the project running so I could look at contributing however encountered an issue getting the project to build (something about command 'tee' not found).
When I migrated some of my own code it was just a case of updating the format of the import statements which I was able to do with a regex find and replace. e.g.
import parse from "date-fns/parse";->import {parse} from "date-fns/parse";I have also found a few places where there are imports from the root of date-fns, these need replacing
import { isSunday } from "date-fns"->import { isSunday } from "date-fns/isSunday "I will have another go at getting the project running next week.
Are there any advantages to importing from the subfolder instead of the root package itself now that everything are named exports? The usage doc themselves show import { isSunday } from "date-fns"; for ESM and you would save on multiple lines of imports from the same package.
Tried to get the project running so I could look at contributing however encountered an issue getting the project to build (something about command 'tee' not found). When I migrated some of my own code it was just a case of updating the format of the import statements which I was able to do with a regex find and replace. e.g.
import parse from "date-fns/parse";->import {parse} from "date-fns/parse"; I have also found a few places where there are imports from the root of date-fns, these need replacingimport { isSunday } from "date-fns"->import { isSunday } from "date-fns/isSunday "I will have another go at getting the project running next week.Are there any advantages to importing from the subfolder instead of the root package itself now that everything are named exports? The usage doc themselves show
import { isSunday } from "date-fns";for ESM and you would save on multiple lines of imports from the same package.
I've found that in some projects which don't have tree shaking importing from the root package results in the WHOLE date-fns package being included in the output bundle instead of just the functions you need. This can result in a much bigger bundle size, especially if using locales.
Only found this out after using https://www.npmjs.com/package/source-map-explorer
Closed via https://github.com/Hacker0x01/react-datepicker/commit/68236d8d82d2e1f4bf94252a7acef4800d027637?
