When my entrypoint is eg src/index.ts and my index.ts is

import {setGlobalOption} from "someFirstModule";
setGlobalOption(); // do a global call here which can set some global state parameter that affect other code definition in the subsequent imports below

export * from "myModuleA";
export * from "myModuleB";
...

I would assume that in the generated code index.mjs the call order be respected (eg the setGlobalOption is called, and then the code from myModuleA and myModuleB is inlined)

right now it's not the case, and my output compiled code is roughly:

... compiled code for myModuleA
... compiled code for myModuleB

setGlobalOption()
export {
 ...all my exports
}

and the issue is that for some libs that I'm using, the setGlobalOption() must be called at the start, so that when the code for myModuleA and myModuleB is executed, it already has the correct options

is it that I should refactor the code differently, or is it a bug in tsup / tsc where the import order of the entrypoint should be respected?

this can also happen in cases where, eg I want to load the ".env.staging" file using dotenv in my index, and then have all the myModuleA, myModuleB, etc directly use process.env.MY_VAR and expect MY_VAR to have correctly been loaded from the dotenv file at that point