Bundle splitting - common chunk has wrong order of modules

[dzearing]

We are seeing a severe issue with splitting related to the ordering of modules within a common chunk. When the app code is bundled with splitting, we have a logger utility which imports a logger context class from a separate file.

// LoggerContext.ts
export class LoggerContext {
  // ...
}

// appLogger.ts
import { LoggerContext } from './LoggerContext';

export const appLogger = {
  context: new LoggerContext()
}

// Page1.tsx (which is split)
import { appLogger } from './appLogger';
// usage of appLogger

When bundling, we correctly see split files and common chunks. However the app crashes because the chunk containing the logger code has the wrong ordering of modules.

Resulted (usage first, then class definition):

// chunk-12341234.js
// Script error on next line here because LoggerContext is undefined.
export var appLogger = { context: new LoggerContext() };
var LoggerContext = class { ... };

Expected order (class first, then usage):

var LoggerContext = class { ... };
export var appLogger = { context: new LoggerContext() };

Many of the split-point pages import appLogger (all synchronously) but none other than appLogger directly refer to the LoggerContext implementation directly, so it's unclear why the class definition is being inserted after usage. Nothing looks off about how things are imported.

If we comment out some of the app imports to try isolating, we have narrowed down some code which when commenting out, changes the common chunk module ordering to be correct. It's unclear specifically why, still investigating. We tried setting up a simple repro, but so far haven't pinpointed the right set of conditions to recreate it.

In looking for related issues, we found this: #399

The title is close to what I'm describing, but I believe that issue is more related to side effects and how chunking can violate assumptions of side effect code. In my scenario, we don't have side effects here - everything is imported as expected. The chunk simply has the wrong order.

I will continue working on an isolated repro, but wanted to get the issue going in case this is known already.

[dzearing]

I think i've figured it out. It's a circular import. The appLogger file exports a const, which the AppContext file imports. Fixing this fixed the ordering.

Closing for now, will re-open I find something different.

[joshmossas]

I just spent a long time trying to figure out why one of our common modules was randomly undefined after bundling.

I finally realized that esbuild was putting the chunks in the wrong order because of a circular import

It would be cool if when bundling esbuild could detect if a circular import has occurred and throw an error. Would've saved me the debugging time 😅