--format=bare or --global={var1, var2}

[retorquere]

I am building Zotero plugins, and for that I must sometimes expose multiple variables in the global context. Would it be possible to either expose the entrypoint "bare" (so all declarations happen in the global scope) or allow multi-var assignment so the bundled code ends up looking like

var {var1, var2} = ...

[evanw]

Why not just do something like Object.assign(globalThis, module.exports)?

[retorquere]

There isn't a globalThis in the context where this code runs.

[retorquere]

Wait -- maybe I'm mistaken. I'll go tinker with the sandbox model Zotero has. Maybe it can be exposed there.

[retorquere]

Zotero is based on FF60ESR, and according to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/globalThis, only FF65+ has globalThis.

[retorquere]

(but there may be no need to rush on this -- I need code splitting, but I can't use esm modules. I'm tinkering with jscodeshift to see if I can transform import and export to writes on a global object a la webpack)

[nettybun]

globalThis refers to window and/or self depending on the context. If you're targeting FF60 then Object.assign(window, ...) should work for you?

[retorquere]

Zotero runs parts of the code (the translators) in a xpcom sandbox, which doesn't have a window -- chrome-level firefox code is halfway between running in a node-ish and web-ish environment.

[retorquere]

Where would I start if I wanted to create a new output format? Firefox extensions have facilities that can mimic esm modules. I'm really keen on starting with esbuild - the speed is unbelievable, and recent versions of webpack have been a pain to use for xpcom Firefox extensions.

[evanw]

I think it should be pretty straightforward to do this with a footer: https://esbuild.github.io/api/#footer. Just use the IIFE format with a footer that looks like var {var1, var2} = yourGlobalName;. Does that work for you?

[retorquere]

Absolutely! That solves my problem for the context where I just need simple bundling. For the other context, I need code splitting, so I'm looking to have esbuild convert my typescript to esm, and then use jscodeshift to transform the import and export declarations.

[retorquere]

Probably not a surprise for you but the speed of esbuild is insane. I must get this to work for my project. I should be thanking webpack for breaking my builds with the releases of the past few weeks -- that's what drove me to seek out alternatives.

[retorquere]

Where would I start adding a new output format? Seems like a shame to hand in a good chunk of the speed gained by having to put it through jscodeshift. Is this something that could be done in a plugin (either go or JS)?

[evanw]

Code splitting is still a work in progress. It is currently undergoing a rewrite and the second half of the linker (the part that deals with output formats) is being completely rewritten. Because of this, I'm not open to adding new output formats at the moment. Still it could be useful to know a little bit about the output format you are looking for. How do imports and exports work?

[retorquere]

import: Components.utils.import
export: EXPORTED_SYMBOLS

but I have to warn that these are methods that Mozilla deems deprecated. Zotero builds on ESR because they're still active there, and all Zotero plugins use this, but it doesn't have a long lifespan left.

I know I'm not supposed to ask for an ETA on the rewrite, but does your current hunch think of it in weeks, months, or years? Pretty keen to get rid of webpack.

[retorquere]

Code splitting is still a work in progress. It is currently undergoing a rewrite and the second half of the linker (the part that deals with output formats) is being completely rewritten.

Does that mean code splitting is fine now but is expected to get better in some way, or that the current code splitting should not be used?

[evanw]

The current form of code splitting is still experimental and should only be used in certain circumstances. It currently only works with the esm output format. There is also a known ordering issue with import statements across code splitting chunks. This is why there is a warning in the documentation for code splitting: https://esbuild.github.io/api/#splitting. For some people the ordering issue is not a concern for their code base and they are already making use of code splitting. Otherwise if those ordering issues are a concern of yours, then esbuild's code splitting should not be used yet.

I don't have a hard ETA for this but I'm hoping to get pretty much everything figured out and shipped sometime in the next month. That said there are significant complexities to doing all of this and it's already taking longer than I had planned earlier. In particular, the ordering requirements of top-level await and external imports are especially tricky to get right. Other bundlers such as Rollup don't even get them right yet.

[retorquere]

I know how those projects go. No worries. I'll just await (ha!) the drop of the rewrite then. One more month of webpack won't kill me, and I do have ordering requirements, albeit only for synchronous code. Maybe I should do something about that anyway.

[evanw]

I'm closing this issue since I'm not planning on implementing this.

[retorquere]

I have a workaround, so no issue.