Open dzearing opened 3 years ago
I have further pinpointed the issue:
Pivot.base.js
imports PivotItem
from ./index.js
, which exports Pivot.base.js
. There's a circular dependency here which I think is confusing the esbuild ordering.
Thanks for the detailed report. I don’t have time to look into this at the moment, sorry (I have an upcoming cross-country move in a few weeks). I hope to be able to look into this after my move is done.
@evanw Thanks, no worries. I've pushed a fix to Fluent UI to remove the cycle from inside of Pivot.base.js
, so that's a workaround on our end. We'll keep going.
I think this is still an issue. @evanw any chance you could take a look?
hi @evanw could you please have a look into solving/providing a workaround strategy for this? thanks, C
From what I am seeing in our app, modules are being resolved breadth-first instead of depth-first. For example:
// index.js
export * from './a/index.js';
export * from './b/index.js';
// a/index.js
export * from './one.js';
export * from './two.js';
// b/index.js
export * from './one.js';
export * from './two.js';
With this example, I am seeing it load in the following order:
/index.js
/a/index.js
/b/index.js
/a/one.js
/a/two.js
/b/one.js
/b/two.js
while the correct load order should be:
/index.js
/a/index.js
/a/one.js
/a/two.js
/b/index.js
/b/one.js
/b/two.js
From what I am seeing in our app, modules are being resolved breadth-first instead of depth-first.
I am seeing this too. How is this not an issue for more people? Flatter lib structure?
From what I am seeing in our app, modules are being resolved breadth-first instead of depth-first. For example:
// index.js export * from './a/index.js'; export * from './b/index.js'; // a/index.js export * from './one.js'; export * from './two.js'; // b/index.js export * from './one.js'; export * from './two.js';
With this example, I am seeing it load in the following order:
/index.js /a/index.js /b/index.js /a/one.js /a/two.js /b/one.js /b/two.js
while the correct load order should be:
/index.js /a/index.js /a/one.js /a/two.js /b/index.js /b/one.js /b/two.js
Issue is still relevant and reproduceable
This issue repros with esbuild 0.12.15:
We're trying to bundle Outlook script with esbuild and we're seeing that files from the
Pivot
from the Fluent UI component library are being bundled in the wrong order. ThePivot
importsPivotBase
and exports astyled
version of it. The expected order in the bundle output is thatPivotBase
gets defined, and then it is used to create/export thePivot
component. We are seeing the reverse: Pivot is defined and exported before PivotBase is defined (lower in the output file.) This causes a null reference in the browser.We found this is due to the
SliderBase.ts
file importingSliderItem
from./index
, which exports bothSlider
andSliderBase
. Changing the import to./SliderItem
fixed the cycle and resolved the issue.Expected: When cyclic dependencies occur (index -> SliderBase -> index), direct import order (Slider -> SliderBase) should control module order in the bundle (first define SliderBase, then define Slider.)
Resulted: The cyclic dependency caused the definition to be reversed (Slider, then SliderBase.)
Isolated repro here:
You should see an error in the console:
If you modify
src/Pivot.ts
to remove thePivotBase
export, or move it above thePivot
export, the bundle will be correctly ordered.Note: the
PivotItem
import inPivotBase
was fixed in Fluent UI 8.23.0.