[BUG] DatePicker component doesn't work with Snowpack

Bug Report Quick Checklist

• I am on the latest version of Snowpack & all plugins.
• I use package manager yarn.
• I run Snowpack on OS Linux.
• I run Snowpack on Node.js v12+ (v14.15.4)

Describe the bug

When trying to use the DatePicker component from react-datepicker, I get this error:

Unhandled Runtime Error
TypeError: callBind is not a function
Source
http://localhost:8080/_snowpack/pkg/object-is.v1.1.5.js [:41:26]
@http://localhost:8080/_snowpack/pkg/object-is.v1.1.5.js:41:26

To Reproduce

1. npx create-snowpack-app react-snowpack --template @snowpack/app-template-minimal
2. cd react-snowpack
3. yarn add react react-dom react-datepicker
4. rm index.js
5. Create index.jsx with this content:

import React from 'react';
import ReactDOM from 'react-dom';
import DatePicker from 'react-datepicker';
import "react-datepicker/dist/react-datepicker.css";

ReactDOM.render(
  <div>
    <DatePicker />
  </div>, 
  document.getElementById('root')
);

1. yarn start
2. You should get the error in the browser window that opens.

Expected behavior

I expect to see the date picker which looks like a text input box and when you click on it you get a calendar to choose the date.

[gpascale]

I looked into this issue independently and believe that @Nivisnum is right on the money with their analysis, however I also believe that changing the value of requireReturnsDefault from ‘auto’ to ‘preferred’ is the proper fix because it would restore behavior that I don’t think was meant to be changed.

The requireReturnsDefault parameter was introduced in @rollup/plugin-commonjs with version 16.0.0. snowpack changed from 15.0.0 to 16.0.0, as far as I can tell, with version 3.1.0, which is why people experiencing this issue have found a workaround in sticking with 3.0.13. This parameter added some complexity to what the plugin returns when resolving a commonjs module that has a default export. In short, the old behavior would always return the default export if it exists - the new parameter allows you to choose between that or additionally ensuring that there are no exports in addition to ‘default’. In 16.0.0, this stricter check is called ‘auto’, which the old behavior is ‘preferred’

Here are the relevant bits in @rollup/plugin-commonjs

@rollup/plugin-commonjs@16.0.0 with requireReturnsDefault: 'auto' (used by snowpack 3.1.0 and later)

function getDefaultExportFromNamespaceIfNotNamed(n) {
  return n && Object.prototype.hasOwnProperty.call(n, 'default') && Object.keys(n).length === 1 ? n['default'] : n;
}

@rollup/plugin-commonjs 15.0.0 (used by snowpack 3.0.13 and before)

export function getCjsExportFromNamespace (n) {
  return n && n['default'] || n;
}

@rollup/plugin-commonjs@16.0.0 with requireReturnsDefault: 'preferred' (same behavior as 15.0.0)

function getDefaultExportFromNamespaceIfPresent (n) {
  return n && Object.prototype.hasOwnProperty.call(n, 'default') ? n['default'] : n;
}

So by setting requireReturnsDefault to ‘preferred’, the resolution behavior will change back to what it was in snowpack in version 3.0.13 and before. I have confirmed this one line change fixes the object-is/call-bind issue for the current version of snowpack.

Now, my hunch is that this change in behavior was an unintended consequence of upgrading @rollup/plugin-commonjs from 15.0.0 to 16.0.0, and therefore setting requireReturnsDefault to ‘preferred’ would restore the original and intended behavior. It seems likely that requireReturnsDefault:'auto' was chosen because it seems like a sensible default and without the intention of changing this behavior. If I am wrong about that, or if there are indeed cases which are fixed by this change in behavior, the only real fix is probably to expose requireReturnsDefault somehow on a per-module basis.

[Dawnthorn]

Yeah. When I filed the bug the latest version of react-datepicker was 3.8.0 and snowpack 3.7.0 still does not work with that version. Snowpack 3.7.0 is working with the new latest version of react-datepicker which is 4.1.1.

It looks like it’s fixed because there’s no longer any call-bind dependency and that’s the the module with the weird exports.