Fix export support for webpack <5.94

[robtayl0r]

---

name: Pull Request
about: Create a pull request to improve this repository
title: Add export support for webpack <5.94
labels: ""
assignees: ""

Description

Linked issue: #(issue number)
5437

Problem

Attempting to import any ./dist/*.css from from react-datepicker 8 will not work in Webpack <=5.93.

import 'react-datepicker/dist/react-datepicker.css';

Module not found: Error: Package path ./dist/react-datepicker.css is not exported from package //node_modules/react-datepicker (see exports field in //node_modules/react-datepicker/package.json)

In react-datepicker 8.0, the exports field was introduced to its package.json. While the expressions in the current export configuration are technically correct in principle, earlier versions of Webpack 5 (<5.94)have quirky behaviour when processing these patterns and combined with its stricter enforement of exports, results in import failures on valid paths.

Webpack's resolver only recently implemented pattern matching parity w/Node.js in Webpack 5.94:

As of version 5.94.0, webpack's behavior has been updated to align with Node's behavior. It now selects the first valid path without attempting further resolutions and throws an error if the path cannot be resolved. (source)

While a simple upgrade of Webpack should solve this problem, this bug is amplified by the fact that many folks still use popular tools locked to older versions of Webpack. CRACO relies on react-scripts which is locked to Webpack 5.75 in perpetuity, as react-scripts is no longer maintained. Next.js >=12 is locked to Webpack 5.64 (as per the final Next.js 12 release). In both cases, overriding Webpack to use a later version isn't possible through conventional package.json override means. In the case of Next.js 12, Webpack is actually bundled into the distribution.

Changes
I've removed the *.css wildcard expression from file exports in package.json. Tested in Webpack 5.75. This does expose all of ./dist to export, however.

Screenshots

To reviewers

Alternatively, I thought of explicitly listing each css file in the package.json exports as the current solution will open all assets in ./dist to exporting. Unsure if this is a problem for the maintainers of react-datepicker. The solution proposed in this PR seems easier to maintain if new css bundles are ever distributed.

e.g.:

    "./dist/*.css": "./dist/*.css",
    "./dist/react-datepicker-cssmodules.css": "./dist/react-datepicker-cssmodules.css",
    "./dist/react-datepicker-cssmodules.min.css": "./dist/react-datepicker-cssmodules.min.css",
    "./dist/react-datepicker-min.module.css": "./dist/react-datepicker-min.module.css",
    "./dist/react-datepicker.css": "./dist/react-datepicker.css",
    "./dist/react-datepicker.min.css": "./dist/react-datepicker.min.css",
    "./dist/react-datepicker.module.css": "./dist/react-datepicker.module.css",

Contribution checklist

• I have followed the contributing guidelines.
• [n/a] I have added sufficient test coverage for my changes.
• I have formatted my code with Prettier and checked for linting issues with ESLint for code readability.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.91%. Comparing base (1122aba) to head (44cd89a).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6033   +/-   ##
=======================================
  Coverage   98.91%   98.91%           
=======================================
  Files          30       30           
  Lines        3496     3496           
  Branches     1470     1487   +17     
=======================================
  Hits         3458     3458           
  Misses         37       37           
  Partials        1        1           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.