Support different export globalNames for multiple entry files in IIFE format

[sean220]

When compiling multiple entry files, only one globalName can be set in build options, which will cause variable naming conflicts. Is it possible to make improves as follows？

1)adding an additional globalName field to the api.EntryPoint struct.
2)change the opt GlobalName’s type from string to []string.

That each compiled file can have a different globalName in IIFE format is very useful for compiling multiple components with their own unique export names in a single building process.

[evanw]

You can easily do this by just building each entry point individually. You can also easily do this by just assigning to window.something for each entry point. Maybe something like this:

import * as something from './this-file'
window.something = something

However, you have to be careful about loading multiple entry points from the same code base on the same page. Some modules are designed to be only instantiated once, and loading them multiple times can lead to weird and subtle bugs (for example: graphql/graphql-js#1479).

[sean220]

Thanks for your reply,my current solution is indeed to build them separately, but the current API supports simultaneous compilation of multiple entry files, it should improve some performance, right? for example,I think the shared dependencies should not to be compiled again? Of course it's fast enough for now.

I am writing a front-end devServer based on esbuild with Golang APIs, especially compiling multiple Vue SFC files,

.vue -> onLoad plugin -> run node (@vue/component-compiler) esm code stdout -> onLoadResult content -> bundle iife js

So I CANNOT control the esm code generated from the pre-compiled SFCs.in the output IIFE format,the SFC component becomes unaccessible without globalName to export. Thats why I need to set a unique globalName for each entry files. The only thing I can do during the build process is:

vue pathname -> globalName (a/b/c.vue -> a.b.c)

Maybe you can consider adding something like globalNameAdvance []string to support this in the future？This can also solve the confusion caused by a single globalName can be set when there are multiple entry files…

[polyscone]

For what it's worth I found myself needing this today and I'm in a similar situation to sean220 where I can't simply add window.foo = foo to each entry point.

For my use case, simply allowing the same [dir], [name], [hash], and [ext] placeholders that are available in entryNames would solve the problem, if that's something you're willing to consider (or perhaps in a separate globalNames option).

For now I've been lucky in that I load JS from the front end myself, so I've been able to set a global name that I can replace in the fetch'd source which I then put into a <script> tag, so I've been able to work around it.

Before hacking in this workaround I had many individual builds running for no other reason than to set globalName, which just seems wrong.