Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESBuild doesn't preserve export * from externalized packages consistently #1737

Open
dzearing opened this issue Nov 2, 2021 · 7 comments
Open

Comments

@dzearing
Copy link

dzearing commented Nov 2, 2021

I'm re-opening this due to getting buried and also because esbuild is producing fundamentally broken output. This could use some eyes.

Setup:

index.js:

export * from './utilities';

utilities.js:

export * from 'foo';

Now create an esm bundle:

esbuild --bundle index.js --outfile=out.js --format=esm --external:foo

Expected:

export * from 'foo';

Resulted:

var __defProp = Object.defineProperty;
var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
var __getOwnPropNames = Object.getOwnPropertyNames;
var __hasOwnProp = Object.prototype.hasOwnProperty;
var __markAsModule = (target) => __defProp(target, "__esModule", { value: true });
var __reExport = (target, module, desc) => {
  if (module && typeof module === "object" || typeof module === "function") {
    for (let key of __getOwnPropNames(module))
      if (!__hasOwnProp.call(target, key) && key !== "default")
        __defProp(target, key, { get: () => module[key], enumerable: !(desc = __getOwnPropDesc(module, key)) || desc.enumerable });
  }
  return target;
};

// index.js
var foo_exports = {};
__markAsModule(foo_exports);

// utilities.js
var utilities_exports = {};
__markAsModule(utilities_exports);
__reExport(utilities_exports, foo_star);
import * as foo_star from "foo";

// index.js
__reExport(foo_exports, utilities_exports);

This makes the bundle unusable in the browser; while I believe star exports are far more fragile than named exports when exporting from an external, it's still completely valid. When encountered, esbuild produces unusable results.

This problem does not repro if the export * from 'foo' is in the entry point (index.js) rather than the sub file (utilities.js).

@dzearing
Copy link
Author

FWIW, this still repros @ 0.14.13.

@aleclarson
Copy link

aleclarson commented Feb 10, 2022

I don't understand why __reExport is used (at all) when the target format is ESM?

@hyrious
Copy link

hyrious commented Feb 10, 2022

Looks like files including import_star has been considered commonjs:

if (record.Flags.Has(ast.ContainsImportStar) || record.Flags.Has(ast.ContainsDefaultAlias)) &&
otherRepr.AST.ExportsKind == js_ast.ExportsNone && !otherRepr.AST.HasLazyExport {
otherRepr.Meta.Wrap = graph.WrapCJS
otherRepr.AST.ExportsKind = js_ast.ExportsCommonJS
}

@taylorhadden
Copy link

Any movement on this? It's currently a full blocker on me moving to Vite.

@dzearing
Copy link
Author

@evanw This is fairly easy to repro, and we are still working around this when we hit it. Basically it's very hard to prevent this from happening if you're bundling things that you don't control (like vendor packages.) Any way to prioritize fixing this one?

@datner
Copy link

datner commented Jul 4, 2023

How can we make sure we avoid a 3 year anniversary to this issue? It's pretty annoying...

@gregjacobs
Copy link

Just ran into this issue as well. What's going on here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants