[BUG] TypeError: (intermediate value).default is undefined

[lauritzsh]

Bug Report Quick Checklist

• [x] I am on the latest version of Snowpack & all plugins.
• [x] I use package manager yarn (Fill in: npm, yarn, pnpm, etc).
• [x] I run Snowpack on OS macOS 11.2.3 (Fill in: Windows, Mac, Linux, etc).
• [x] I run Snowpack on Node.js v12+

Describe the bug

I had to skip Snowpack 3.2.0 because it had some rimraf issue but 3.3.0 seemed to build correctly. However, when I run it locally I see the following:

Unhandled Runtime Error

TypeError: (intermediate value).default is undefined
Source

http://localhost:8080/_snowpack/pkg/intl-messageformat.v2.2.0.js [:429:47]

core<@http://localhost:8080/_snowpack/pkg/intl-messageformat.v2.2.0.js:429:47
createCommonjsModule@http://localhost:8080/_snowpack/pkg/intl-messageformat.v2.2.0.js:10:5
@http://localhost:8080/_snowpack/pkg/intl-messageformat.v2.2.0.js:295:32

It is not something I'm directly depending on but something that react-aria seems to depend on. Haven't seen this issue before so I have to revert back to 3.0.13 for now.

To Reproduce

1. npx create-snowpack-app react-snowpack --template @snowpack/app-template-minimal
2. npm install react-aria
3. Edit the index.js to include react-aria, something like

   import * as aria from "react-aria";
   console.log(aria);

4. npm run start
5. See error!

Expected behavior

That the app would run correctly like it did with 3.0.13.

[stephenh]

I hit this as well, looks like intl-messageformat has a known-ish (but closed) issue about one of their dependencies not supporting ESM yet:

https://github.com/formatjs/formatjs/issues/1913

Which people on that issue have been working around by pulling it from jspm.dev:

// In es-dev-server.config.js
module.exports = {
  middlewares: [
    function rewriteFastMemoize(context, next) {
      if (context.url === '/node_modules/fast-memoize/src/index.js') {
        context.status = 302;
        context.redirect('https://jspm.dev/fast-memoize');
        return;
      }
      return next();
    },
  ],
};

Not sure how to do that in snowpack.

[stephenh]

FWIW the (...value...).default is undefined runtime error happens on this line:

es5.defineProperty(MessageFormat, '__parse', {value: intl$messageformat$parser$$["default"].parse});

Where the ...$parser$$... import is:

import intl$messageformat$parser$$ from '/_snowpack/pkg/intl-messageformat-parser.v1.4.0.js';

So for some reason, that import is returning undefined now (actually this isn't right, see next comment), and sounds like it did not before, in snowpack v3.0.13.

[stephenh]

So one module, intl-messageoformat-v2.2.0, is trying to look up ...other-module...["default]":

es5.defineProperty(MessageFormat, '__parse', {value: intl$messageformat$parser$$["default"].parse});

And when I look in the "other-module", intl-messageformat-parser-v1.4.0, source code (within dev tools), I see do parse in there:

var parser = (function() {
  ...lots of code...
  return {
    SyntaxError: peg$SyntaxError,
    parse:       peg$parse
  };
})();

export default parser;

So it looks like there should be a default export, but when I look at the module's runtime value in the debugger, it's just parse and SyntaxError directly, and no default key:

So, it looks like snowpack is getting confused about whether there's a default export on this module or not.

It looks like there should be (the imported module's source uses export default parser) and trying-to-import-module code thinks it should be (it's doing module["default"].parser) ... but the module that actually exists at runtime doesn't have it.

Where / how would this miscommunication be happening?

[stephenh]

FWIW I've got the same codebase running on vitejs (I'm doing a shoot-out of the two systems). Not sure if that helps or not.