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

externalized export * of package from sub file does not emit in bundle #1521

Closed
dzearing opened this issue Aug 13, 2021 · 3 comments
Closed

Comments

@dzearing
Copy link

dzearing commented Aug 13, 2021

We are trying to create ESM bundles for any given package by externalizing dependencies. We're seeing the bundles unconsumable by the browser when the source exports * from an external dependency anywhere other than the root entry file. Repros on 0.12.20.

Setup:

index.js exports all named exports from utilities:

export * from './utilities';

./utilities.js exports all named exports from the foo package (to be externalized):

 export * from 'foo';

I create an esm bundle with utilities.js directly which externalizes foo:

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

Result in out.js (as expected):

export * from 'foo';

Now, create the same bundle but pointing to index.js:

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

I expect exactly the same output. Instead there is no export * from 'foo' anywhere, and as such consumers can't access the named exports from foo.

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 test_imports_exports = {};
__markAsModule(test_imports_exports);

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

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

I can't seem to create a correct esm bundle for a package if it re-exports another package anywhere other than the entrypoint.

@dzearing dzearing changed the title externalized export * from entry has different behavior than the same export from imported file externalized export * from entry file has different behavior than from sibling file Aug 13, 2021
@dzearing dzearing changed the title externalized export * from entry file has different behavior than from sibling file externalized export * of package from sub file does not emit in bundlehas different behavior than from sibling file Aug 16, 2021
@dzearing dzearing changed the title externalized export * of package from sub file does not emit in bundlehas different behavior than from sibling file externalized export * of package from sub file does not emit in bundle Aug 16, 2021
@dzearing
Copy link
Author

@evanw Any ideas here?

This is a very common situation; we actually want to recommend that consumer code removes file path imports and minimizes the dependencies to package imports, but this particular bug blocks that because packages like Fluent UI have the entry point index.ts export * from files like FooComponent.ts, which may in turn export * from "react-foo-component". This is done to support both entry points, but using esbuild to produce the esm which externalizes the react-foo-component package, the index entry will not actually export * from react-foo-component.

Our workaround is to modify consumer code to directly import from @fluentui/react/lib/FooComponent to work around this bug until we can produce bundles which can preserve the export * in the bundle output. But this workaround is pretty terrible because we want to do the opposite: replace all imports with package-based imports (e.g. @fluentui/react instead of @fluentui/react/lib/FooComponent)

@dzearing
Copy link
Author

@evanw wondering if we should dig into the code and try to fix and submit a PR, or if you possibly know where the issue is. Any starter tips on where we should start looking would be appreciated :)

@dzearing
Copy link
Author

dzearing commented Nov 2, 2021

Closing, reopened #1737.

@dzearing dzearing closed this as completed Nov 2, 2021
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

1 participant