Support output.globals for other formats

[eight04]

Related: #1665

Currently, output.globals is only used if format is iife or umd. If format is es and we want to map the external module to a global variable, we usually solve it with a shim/alias plugin (e.g. export default $). However, this solution doesn't work well with experimentalCodeSplitting. When code splitting is enabled, the shim module would be chunked instead of being inlined:
entry.js

import $ from "./chunk-xxx.js";
...

entry2.js

import $ from "./chunk-xxx.js";
...

chunk-xxx.js

export default $;

By enabling output.globals for other formats, we can avoid sharing the shim module.

Another solution is to enable code splitting for iife when there is no shared dependency (or marking all shared dependencies as externals). Related: #2072

[eight04]

I made a plugin to handle this:
https://www.npmjs.com/package/rollup-plugin-external-globals

[lukastaegert]

+1 from me, I think this would make the experience much more consistent. It might not be easy to implement, though. At the moment, this option is only handled in the wrapper code added for the format.

It might be possible to handle this via adjusting the rendering logic to protect the globals from being deconflicted and just use the global names whenever the import is accessed.

[lukastaegert]

BTW had a look at your plugin, very nice! Seems the only thing missing is to hook it to the deconflicting mechanics (which is not directly exposed to plugins). To properly link it here, this would also resolve #2357.

[shellscape]

Hey folks. This is a saved-form message, but rest assured we mean every word. The Rollup team is attempting to clean up the Issues backlog in the hopes that the active and still-needed, still-relevant issues bubble up to the surface. With that, we're closing issues that have been open for an eon or two, and have gone stale like pirate hard-tack without activity.

We really appreciate the folks have taken the time to open and comment on this issue. Please don't confuse this closure with us not caring or dismissing your issue, feature request, discussion, or report. The issue will still be here, just in a closed state. If the issue pertains to a bug, please re-test for the bug on the latest version of Rollup and if present, please tag @shellscape and request a re-open, and we'll be happy to oblige.

[adjenks]

So... If I use es, I can't use output.globals and if I use umd I can't use code splitting?

So I must either use this plug-in for adding output.globals to es, or I must add a plugin to make code splitting work in umd or perhaps iife like this one: rollup-plugin-iife?

@lukastaegert Can you re-open this? I think it's still an problem. I don't think it should be managed by a plugin. If you do think it should be managed by a plugin, why?

I was already using a plugin called 'rollup-plugin-peer-deps-external' to make all of my peer deps external, but rollup-plugin-external-globals does not use the external setting. Rollup is great and the The amount of plugins I need to use to make a simple website is getting out of hand...

Also, although I can settle on using the rollup-plugin-iife plugin, I'd rather output UMD because it creates global variables in the browser when I have an export defined whereas this plugin does not, so I have to explicitly write globalThis.ModuleName = ModuleName || {exportedStuff} at the bottom of my module, which is not very cool.

Any idea how I can get dynamic imports with a umd output format?I it seems other discussions suggest that rollup doesn't want to do this but other build tools do it. So if rollup won't do it, how do I workaround that to stay with rollup?

[curran]

I faced a similar challenge and this is the solution I landed on: https://github.com/curran/rollup-react-pwa-example

Long story short:

• The main client bundle uses iife format, so Rollup globals config works fine there.
• The lazy loaded client bundle uses amd format. Rollup globals config does not work there, however I used the aliases feature of d3-require (lightest AMD loader I could find) to accomplish the same thing.

[tschaub]

The rollup-plugin-external-globals package can't be installed with Rollup 4 due to its peer dependencies. Does anyone know if there is an alternative that works for Rollup 4?

[shellscape]

@lukastaegert have resisted getting into the business of maintaining one, but maybe it's time

[tschaub]

In our case, we're generating an iife build, and I'm surprised that output.globals isn't working. I assumed that Rollup wouldn't even try to parse dependencies in this output.globals lookup, but it looks like that is not the case. We were using the rollup-plugin-external-globals plugin to work around this.

I should try to create a simpler reproducible example, but here is a commit where I try to replace rollup-plugin-external-globals with the output.globals config: openlayers/openlayers@effc559. And some detail on the failure here: openlayers/openlayers#15241 (comment)