cannot resolve dependencies when building library as chunks

[obiot]

Rollup Version

3.2.5

Operating System (or Browser)

OSX Ventura / Safari 16.1 / Chrome 107

Node Version (if applicable)

19 (but not applicable)

Link To Reproduction

https://jsfiddle.net/9f1av85x/

Expected Behaviour

Should display "Hello World" as in this working Fiddle:
https://jsfiddle.net/obiot/4o9f02tc/

Actual Behaviour

With the latest release of our library, we switched to Rollup 3, and added one melon.mjs build that is basically a directory with all the es6 chunks (to enable proper tree shaking with bundlers).

When executing the hello world example, the browser is not able to find the extending class and throwing an exception, either "ReferenceError: Cannot access uninitialized variable." in Safari, or "Uncaught ReferenceError: Cannot access 'Renderable' before initialization" in Chrome.

the error is happening on this class https://github.com/melonjs/melonJS/blob/master/dist/melonjs.mjs/renderable/container.js, within the build, where it cannot find the extending Renderable class (corresponding "untransformed" source code is here : https://github.com/melonjs/melonJS/blob/master/src/renderable/container.js)

Rollup config file: https://github.com/melonjs/melonJS/blob/master/rollup.config.mjs

Note: it was working at some point with Rollup 2 and some workaround in the rollup config file, but since the move to rollup 3 we have that error and we are out of idea on why this is happening.

thank you in advance !

[lukastaegert]

Sounds like an issue with execution order, or an issue with chunking that triggers a wrong execution order. It would surprise me to be caused by Rollup 3 itself as there should not be any changes in that area.
So, questions:

• Did you also update plugins? If so, is everything working when you just update the plugins but do not update Rollup itself?
  • If not, then pinpointing the problematic plugin update would be the next step. I would especially look at the commonjs and node-resolve plugins.
• If it is the Rollup update itself, is everything working for the very latest Rollup 2 version?

[obiot]

hi, thanks for the feedback, and sorry for the late reply.

Yes, we updated all the plugins.

About the order, that's what I thought as well, but we have been very careful when importing all our classes so that the execution order is correct.
https://github.com/melonjs/melonJS/blob/master/src/index.js

And finally, we had it working with Rollup 2 previously (see melonjs/melonJS@d60d2ff), but it was based on a workaround that was described here #3684, and we ultimately reverted the changes while waiting for rollup 3 to be release as the workaround was causing issues with external (NPM) dependencies.

it's maybe indeed something really obvious that we are missing, but honestly I don't / can't see what.

[lukastaegert]

No, I really do not think you are messing up execution order but something within either Rollup or plugins. What I wanted you to do is to rule out the plugins first. Because all updated plugins are still compatible for Rollup 2, so my question wa: If you stick to your workaround version with Rollup 2 and just update all plugins, are things still working?

[obiot]

Hi @lukastaegert, sorry for the laaaate feedback, but it took me quite a while to be able to pin down what was causing this and how to fix it.

It turns out that the culprit was this line that was messing up with the class order :
melonjs/melonJS@44d79fc
and causing the Renderable Class to be declared after the Container Class (where Container actually extends Renderable)

First it was only on the chunks we generate for the .mjs build, but then along with the latest update, I realized that even our es6 bundle was affected, so really a general build issue.

I thought it was maybe link to #995, but the funny thing here is that there is no really any other dependencies with either of them, as beside (previously) accessing Container.prototype.reverseSortZ, there is no reference to Renderable or anything, nor extending neither of them, so I can't really understand why it was causing the issue.

long story short though, it does work now ! You can close this one I guess, but If I may maybe we need a better built-in way to identify circulars dependencies in Rollup, rather that having to rely on 3rd party tools. At least to get some warnings or something on the most "heavily" circular ones (if it's a correct thing to say).

Anyway, thank you again !