Systemjs: Retaining the global environment require

[Nedlinin]

Using 0.19.24 I can pull the Esri JS API from their CDN

        <!-- ArcGIS api -->
    <script src="https://js.arcgis.com/3.16/"></script>

And use their require directly (it's global and can also be referenced at dojo.require).

require([
       "esri/map"
    ], (Map) => {
        this.map = new Map("mapDiv", {
            zoom: 15,
            logo: false,
            maxZoom: 18,
            minZoom: 14
        });
    });

However, upgrading to SystemJS 0.19.25 kills this ability and leaves me with:

Uncaught (in promise) TypeError: require is not a function(…)attached @ eimMap.js:47

EDIT: I should state that using dojo.require instead also does not fix the issue..

init.js:83 Uncaught (in promise) TypeError: a.replace is not a function(…)

So it appears to get a bit further into the script but still fails out.

[guybedford]

The reasoning here is that some modules will decide to branch into AMD or global behaviours in UMD patterns based on the existence of the global require. So allowing the require global to be redefined is effectively creating inconsistency in the way modules load.

Perhaps we can make it possible to have exceptions like this, allowing a global require mode that then only removes the scoped require like you get in NodeJS (in NodeJS global.require is not defined). The alternative would be to call this require something else.

[AStoker]

This is breaking something we have in our system. Until it's resolved, can I lock down the version of systemjs that jspm is using? I know it's slightly off topic, as this issue is for systemjs, not jspm. But I'm pulling at straws.

[guybedford]

@AStoker the version of jspm locks with the version of SystemJS, so definitely lock jspm then in that case until we have a solution here.

[AStoker]

Gotcha, thanks.

[AStoker]

And back to the issue at hand. You're saying that due to require being defined globally, it might cause modules in UMD to take a specific path, and that's why it's not working, to stop any kind of inconsistency?

[guybedford]

@AStoker yes exactly, but this maybe over-cautious as I believe most patterns are supposed to check for exports not require.

I've gone ahead and reverted this change in https://github.com/systemjs/builder/commit/d12658723801ee8209a758825a8ceb4cf84ce8c9 and https://github.com/systemjs/systemjs/commit/cbfb7f724d74cc333783eda19e03c5ce3e1505c4.

The SystemJS change will then avoid the require from the SystemJS execution scope itself leaking into module executions, which was the main issue, while still ensuring that any globally defined require remains available.

Will post the release with this soon.

[guybedford]

Released in 0.19.26.