import 'react-datepicker' returns a commonjs module with esbuild

[fijiwebdesign]

Describe the bug

We switched our build to esbuild and now react-datepicker returns a commonjs module for the ES6 import.

Note: package.json is set to "type": "module",

To Reproduce

import ReactDatePicker from 'react-datepicker'

export default () => <ReactDatePicker />

The above will error as ReactDatePicker needs to be ReactDatePicker.default:

import ReactDatePicker from 'react-datepicker'

export default () => <ReactDatePicker.default />

Expected behavior

Should import ReactDatePicker as ES6 module.

[buildingwatsize]

@fijiwebdesign and For any Googler, I found some useful trick for use this library with dynamic way.

1. Import

import DatePicker from "react-datepicker";

2. Re-define to a variable (Note that ?? is Nullish Coalescing)

const ReactDatePicker = DatePicker.default ?? DatePicker;

3. Use variable instead

<ReactDatePicker />

It would be perfect for all you guy who stuck with ES module import issues.

Bonus

for Thai people or Buddhist who need a date picker library which support completely about the leap year and be standalone which don't need to import any css files. I made a library which implemented from react-datepicker. It called thaidatepicker-react. Anybody can check this out on NPM or GitHub. Thank you.

[Suppen]

I struggled with this issue for a looooooong time.

I initially made a bunch of components in a project, but soon figured out that these would be better as a separate package. One of the components was a date input which wrapped DatePicker.

When part of the project, everything worked fine. When I separated the components to its own package and imported that to the main project, everything except the date input worked.

I eventually figured out that when importing react-datepicker in the main project, I got a function, i.e. the component itself. However, when I imported my package which imported react-datepicker, the result was an object, an ES module, even though the import statements were identical, and both should get the default export.

@buildingwatsize's answer turned out to solve the problem. It is a hack, but it works.

Adapted for TypeScript, with a nasty type hack:

import ReactDatePicker from "react-datepicker";

const DatePicker =
  (ReactDatePicker as unknown as { default: typeof ReactDatePicker }).default ??
  ReactDatePicker

...

<DatePicker ... />

[mattijauhiainen]

To me it looks like this issue would be caused by the "browser": "dist/react-datepicker.min.js" in react-datepicker's package.json

Diving deeper

• That minified file contains commonjs module, not esm one
• Looking at webpack docs, webpack will look at main fields with in the order of "browser", "module" and finally "main" (https://webpack.js.org/configuration/resolve/#resolvemainfields)
• So here it would decide to import from whatever "browser" points to
• If I take the "browser" export out of package.json, webpack will pull from "module" instead which points "dist/es/index.js", and things start to work.

Not sure if the bug here is webpack or the react-datepicker, but exposing es6 module as the browser export would make more sense here and probably would fix this?

vite + rollup seems to handle this same situation correctly

[vitkarpov]

I can confirm the same issue after migration from vite@3.x to vite@4.x. A work-around suggested by @Suppen worked for me.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[lveillard]

Hello! In my case i have react-datepicker in /ui package in a monorepo, and using this ui package in a nextjs app.

When doing so, I have a related issue when react-datepicker imports date-fns:

Error: Module not found: ESM packages (date-fns) need to be imported. Use 'import' to reference the package instead. https://nextjs.org/docs/messages/import-esm-externals

https://nextjs.org/docs/messages/module-not-found

Import trace for requested module:
../../packages/ui/dist/index.mjs

@Suppen workaround did not work for me, but adding

  experimental: {
    esmExternals: 'loose',
    }

in next.config.js did workaround it.

This options breaks the new turbopack bundler tho, so fixing the root cause of this commonjs export would be lovely!

Hope it helps