v0.10.2 appears to produce circular references where `__commonJS` is not defined #1070

pheuter · 2021-03-27T21:27:02Z

TypeError: undefined is not a function (near '...__commonJS...')

This likely has to do with the breaking changes in v0.10.0, No longer support module or exports in an ESM file. I'm guessing at some point in the dependency chain there's an isarray npm module being required and it has some problematic usage of module exports?

The problem is I have no control over this particular dependency.

The text was updated successfully, but these errors were encountered:

pheuter · 2021-03-27T21:29:02Z

UPDATE: Upon further debugging, it appears that this issue only comes up in v0.10.2, and appears to work fine in v0.10.0.

evanw · 2021-03-27T21:34:27Z

Is it possible to provide a code sample that would allow me to reproduce the problem?

pheuter · 2021-03-27T21:54:17Z

Having difficulties reproducing in an isolated code sample, but have some more info from digging deeper.

Two files are generated: index.js and chunk-xyz.js:

index.js (sample from top of file)

import {
  DeveloperMode,
  PrivateRoute,
  ProvideAuth,
  QueryClientProvider,
  React,
  Subscribable,
  __commonJS,
  __toModule,
  _extends,
  _inheritsLoose,
  _objectWithoutPropertiesLoose,
  // ... more app-specific dependencies
} from "/build/chunk-xyz";

// ../node_modules/isarray/index.js
var require_isarray = __commonJS((exports, module) => { // NOTE: this is where the error is thrown
  module.exports = Array.isArray || function(arr) {
    return Object.prototype.toString.call(arr) == "[object Array]";
  };
});

chunk-xyz.js (sample from top of file)

import {
  Route,
  define_BUILD_ENV_default,
  useMutation
} from "/build//.//index.js";
var __create = Object.create;
var __defProp = Object.defineProperty;
var __getProtoOf = Object.getPrototypeOf;
var __hasOwnProp = Object.prototype.hasOwnProperty;
var __getOwnPropNames = Object.getOwnPropertyNames;
var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
var __markAsModule = (target) => __defProp(target, "__esModule", {value: true});
var __commonJS = (cb, mod) => () => (mod || cb((mod = {exports: {}}).exports, mod), mod.exports);
var __export = (target, all) => {
  for (var name in all)
    __defProp(target, name, {get: all[name], enumerable: true});
};

If I'm understanding correctly, there's a possible circular reference here between index.js and chunk-xyz.js, so when index depends on __commonJS coming from chunk, it isn't actually defined yet?

evanw · 2021-03-27T23:05:31Z

The bug here seems to be that a circular reference is generated in the first place. I believe one shouldn't ever be generated at all. The bug is presumably something to do with the Route, define_BUILD_ENV_default, and useMutation imports. If these symbols are used from another entry point other than index.js, then they should be moved into the shared output file chunk-xyz.js instead of residing in the entry point output file index.js. Unfortunately this is going to be tough for me to fix without a way to reproduce it myself. I checked and I can't reproduce this on any of my test projects.

Independent of that, this part of your reply also had me confused:

Two files are generated: index.js and chunk-xyz.js:

Is that true? If so, are you attempting to load chunk-xyz.js instead of loading index.js? That would give you this error:

$ cat index.mjs 
import { __commonJS } from "./chunk-xyz.mjs";
var require_isarray = __commonJS();

$ cat chunk-xyz.mjs 
import "./index.mjs";
export var __commonJS = () => {};

$ node index.mjs 

$ node chunk-xyz.mjs 
index.mjs:2
var require_isarray = __commonJS();
                      ^

TypeError: __commonJS is not a function

But the entry point index.js should be loaded first because it's the entry point.

pheuter · 2021-03-27T23:23:16Z

I have a single entrypoint:

entryPoints: ['./src/index.tsx'],
bundle: true,
splitting: true,
format: 'esm'

that's loaded like so:

<body>
  <div id="app"></div>
  <script src="build/index.js" type="module"></script>
</body>

Within that entrypoint, I do make use of lazy loading to create chunks for routes that have large dependencies, like the Dashboard view that pulls in a charting library:

(snippet simplified for the purposes of sharing—React Suspense is loaded properly here)

import './styles/base.css';

const Dashboard = lazy(() => import('./modules/Dashboard'));

function App() {
  return (
    <Route path="/dashboard">
      <Dashboard />
    </Route>
  );
}

After esbuild runs, it generates all of these files:

index.js
index.css
chunk-xyz.js
modules/Dashboard/index.js

Both index.js and modules/Dashboard/index.js import from chunk-xyz.js, and for some reason at the very top of chunk it imports those 3 items you called out from the top level index.js.

pheuter · 2021-03-28T14:19:38Z

One weird thing I'm noticing is simply changing the name of one of my global define variables removes it from the chunk import:

In esbuild config:

define: {
    global: JSON.stringify({}),
    'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV),
    __VERSION__: JSON.stringify(packageJson.version),
    __COMMIT_HASH__: JSON.stringify(commitHash),
    __BUILD_DATE__: JSON.stringify(new Date()),
    __BUILD_ENV__: JSON.stringify(clientBuildEnv)
}

Top of chunk:

import {
  Route,
  define_BUILD_ENV_default,
  useMutation
} from "/build//.//index.js";

And then top of chunk after renaming __BUILD_ENV__ to __BUILDENV__:

import {
  Route,
  useMutation
} from "/build//.//index.js";

ggoodman · 2021-03-29T20:34:59Z

~~I'm also observing this issue but also don't have a small reproduction (yet).~~

Perhaps it's worth noting that I have a circular dependency loop but for type-only imports. @evanw maybe that bit of info could help identify the issue. That circular dependency is reported by separate tooling (rollup-plugin-dts). That being said, it seems as if the circular dependency is being produced by tsc and may not exist in the original source 🕵🏼.

EDIT: Spoke too soon. There was indeed a circular dependency in the code.

pheuter · 2021-03-30T12:15:14Z

It looks like v0.11.2 fixes the issue I was having on v0.10.2 with no code changes in the app. There's still a couple of imports at the top of chunk.js but it no longer results in any runtime errors.

evanw · 2021-04-03T21:33:34Z

This is likely a duplicate of #1081.

evanw · 2021-04-03T21:46:10Z

Could you check again with version 0.11.5? I suspect that this issue will be resolved by the latest release.

pheuter · 2021-04-04T15:08:28Z

@evanw 0.11.5 works 👍

pheuter · 2021-04-04T15:08:37Z

fwiw it worked in 0.11.2 as well

evanw · 2021-04-07T08:31:00Z

Closing as it sounds like this has been fixed.

pheuter changed the title ~~v0.10.0 appears to break deeply nested npm module isarray~~ v0.10.2 appears to break deeply nested npm module isarray Mar 27, 2021

pheuter changed the title ~~v0.10.2 appears to break deeply nested npm module isarray~~ v0.10.2 appears to produce circular references where __commonJS is not defined Mar 27, 2021

evanw mentioned this issue Apr 4, 2021

Non-deterministic module ordering with splitting: true (affects chunk hashes) #1075

Closed

evanw closed this as completed Apr 7, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

v0.10.2 appears to produce circular references where `__commonJS` is not defined #1070

v0.10.2 appears to produce circular references where `__commonJS` is not defined #1070

pheuter commented Mar 27, 2021 •

edited

Loading

pheuter commented Mar 27, 2021 •

edited

Loading

evanw commented Mar 27, 2021

pheuter commented Mar 27, 2021 •

edited

Loading

evanw commented Mar 27, 2021

pheuter commented Mar 27, 2021 •

edited

Loading

pheuter commented Mar 28, 2021 •

edited

Loading

ggoodman commented Mar 29, 2021 •

edited

Loading

pheuter commented Mar 30, 2021

evanw commented Apr 3, 2021

evanw commented Apr 3, 2021

pheuter commented Apr 4, 2021

pheuter commented Apr 4, 2021

evanw commented Apr 7, 2021

v0.10.2 appears to produce circular references where __commonJS is not defined #1070

v0.10.2 appears to produce circular references where __commonJS is not defined #1070

Comments

pheuter commented Mar 27, 2021 • edited Loading

pheuter commented Mar 27, 2021 • edited Loading

evanw commented Mar 27, 2021

pheuter commented Mar 27, 2021 • edited Loading

evanw commented Mar 27, 2021

pheuter commented Mar 27, 2021 • edited Loading

pheuter commented Mar 28, 2021 • edited Loading

ggoodman commented Mar 29, 2021 • edited Loading

pheuter commented Mar 30, 2021

evanw commented Apr 3, 2021

evanw commented Apr 3, 2021

pheuter commented Apr 4, 2021

pheuter commented Apr 4, 2021

evanw commented Apr 7, 2021

v0.10.2 appears to produce circular references where `__commonJS` is not defined #1070

v0.10.2 appears to produce circular references where `__commonJS` is not defined #1070

pheuter commented Mar 27, 2021 •

edited

Loading

pheuter commented Mar 27, 2021 •

edited

Loading

pheuter commented Mar 27, 2021 •

edited

Loading

pheuter commented Mar 27, 2021 •

edited

Loading

pheuter commented Mar 28, 2021 •

edited

Loading

ggoodman commented Mar 29, 2021 •

edited

Loading