Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with date-fns imports (_____ is not a function) #367

Open
owattenmaker opened this issue Feb 6, 2024 · 10 comments
Open

Issue with date-fns imports (_____ is not a function) #367

owattenmaker opened this issue Feb 6, 2024 · 10 comments

Comments

@owattenmaker
Copy link

Just trying out this library. I noticed you've just switched over to using date-fns which is great since I already use this in my project.

On install and open however I get errors with the way you import functions from date-fns.

for instance you have:

import { getMonth } from "date-fns/getMonth"

this fails for me. However either

import getMonth from "date-fns/getMonth"

or

import { getMonth } from "date-fns"

works. Each of the individual files from date-fns just have default exports, and no named export. Or the index file has the named export. Unsure of which version you're using of date-fns, this is for version 2.30.0 for me locally.

Anyone else? solutions? I will use this library with a patch package to fix the imports so they work for me, but should be a simple fix for everyone else.

@peacechen
Copy link
Collaborator

@tranjog updated this library to use date-fns. Did date-fns change their exports between versions?

@owattenmaker
Copy link
Author

owattenmaker commented Feb 6, 2024

I do see some breaking changes from v2 to v3 mentioning imports. https://date-fns.org/v3.3.1/docs/Change-Log#v3.0.0-2023-12-18

So that must be it.

You may wish to add a peer dependency of v3 or higher.

Additionally, I did try upgrading to version 3 of date-fns, but it appears that date-fns-tz library is not yet updated to work with v3, so I cannot do this. Perhaps you could just switch to using the import { name } from "date-fns" format which works with both v2 and v3.

@peacechen
Copy link
Collaborator

That's it. They really shouldn't have broken imports like that. It would have been better for them to export both the default and named versions.

The peer deps should have this set to >= 3.0 to inform users that's needed.

@tranjog
Copy link
Contributor

tranjog commented Feb 7, 2024

Comparing the date-fns source files, v3 does named exports only:
addDays v3

and v2 does default exports only:
addDays v2

However, both support
import {addDays} from 'date-fns'

So it'll be trade-off between supporting both v2 and v3 and giving up (potential) tree-shaking benefits by importing from date-fns/addDays, or only supporting >= 3.0.

Any opinions on this? I'm leaning towards the former.

@peacechen
Copy link
Collaborator

peacechen commented Feb 7, 2024

Supporting older versions isn't a good use of resources IMHO. It may be useful temporarily, but long term it's throw-away work. It's not a heavy burden for consumers of this library to upgrade to date-fns 3.x.

Another option is to create a beta release branch that modifies the imports to support 2.x. That would be a dead-end branch and not maintained unless someone who needs it contributes to doing the work.

@tranjog
Copy link
Contributor

tranjog commented Feb 7, 2024

Okay, thanks! I'll update the peer dependency only, the README already states that we require date-fns >=3.0.

What about: "Whilst we do not officially support date-fns 2.x, you can apply this patch file at your own risk" and link to this thread?

Would you be able to upload your patch @owattenmaker ?

@peacechen
Copy link
Collaborator

A patch is a last resort option when the maintainers aren't available. Since we're here to publish new versions, it would be best to commit the changes to a branch and publish an alpha version that doesn't get pulled by npm unless specifically requested.

I've made a branch datefns2 for this. @owattenmaker please create an MR that targets this branch.

@DFRZ7
Copy link

DFRZ7 commented Jun 2, 2024

Hi, just wanted to mention that the I had to create a patch as well in order to move forward on this.

Changing from:

-import { getMonth } from 'date-fns/getMonth';
-import { getYear } from 'date-fns/getYear';
-import { isSameDay } from 'date-fns/isSameDay';
-import { isSameMonth } from 'date-fns/isSameMonth';

to:

+import getMonth from 'date-fns/getMonth';
+import getYear from 'date-fns/getYear';
+import isSameDay from 'date-fns/isSameDay';
+import isSameMonth from 'date-fns/isSameMonth';

Helped us out.

Will keep an eye on this.

Thank you.

@AleksandrTermenzhy
Copy link
Contributor

AleksandrTermenzhy commented Aug 1, 2024

Hey @peacechen,

I wonder, given this incompatibility with the pre-3 versions of the date-fns, is there any reason for not updating peerDependancies of the library to something more specific:

"peerDependencies": {
    "date-fns": "^3.0.0"
}

As now it causes issues in a monorepo setup when other libraries define lower date-fns version.

@peacechen
Copy link
Collaborator

@AleksandrTermenzhy Yes that would help to avoid/notify other libraries that are using lower versions. Would you mind submitting a PR that changes both the peer dependency and dev dependency version to >= 3.0.0 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants