Conflicting SystemJS instances — how to resolve?

[halostatue]

Conflicting SystemJS instances — how to resolve?

[halostatue]

This works, but it is as ugly as it sounds.

[halostatue]

I was exploring new System.constructor(), but that does not help me as it appears to be a full clone of the parent SystemJS (with configuration) instead of being a fresh unconfigured instance that I could then call mySystem.import(entry_url) and have reasonable assurance that it would work since that is how we are using our SJS.

[erikt9]

Although hacky and unsupported, you can make your own custom build of systemjs. The main thing of interest is that SystemJS installs itself to envGlobal https://github.com/systemjs/systemjs/blob/main/dist/s.js (line 14 and 504) which is defined as the unqualified variable self if present.

var envGlobal = hasSelf ? self : global;
.
.
.
envGlobal.System = new SystemJS();

So in an IIFE you can define your own self variable and SystemJS will install itself into that.

(function() {
var self = {};

// copy s.js to here

window.MySystemJS = self;

})();

Now you can call MySystemJS.System.import(...) and be completely isolated

[halostatue]

Now you can call MySystemJS.System.import(...) and be completely isolated

As far as I can tell, I would need to also modify my bundles (created by Rollup using format: system) to refer to MySystemJS.System.register. Am I correct about that, or will the System.register that the downloaded bundles see be scoped to MySystemJS.System?

[erikt9]

As far as I can tell, I would need to also modify my bundles (created by Rollup using format: system) to refer to MySystemJS.System.register. Am I correct about that, or will the System.register that the downloaded bundles see be scoped to MySystemJS.System?

Yes, unfortunately you are right about that (most of my modules are globals, so I wasn't thinking of System.register()). Some (not very good choices) I can think of:

1. As you suggested, change all your System.register to MySystemJS.System.register in your modules (could probably be a sed script you run on your output).

2. If you only have to worry about System being defined, but not amd methods (define), instruct rollup to produce amd modules and use the amd compatibility mode of SystemJS. You'd also need to copy the define method from MySystemJS to window at the bottom of the code above. Semantics of amd are a bit different than SystemJS, so may or may not work depending on how complex your imports are.

3. If it's safe to target only browsers implementing fetch, you can put SystemJS in its fetch-eval mode (override the shouldFetch method to always return true). Then you make a custom eval (which your version of System would use) where you swap with the global System and then eval:

(function() {
var self = {};

// note: redefining eval like this is not supported in strict mode, but will work in a `loose` function
var eval = function(code) {
  var backupSystem = window.System;
  try{
    window.System = self.System;
    window.eval(code); // indirect call of eval -- will always execute in the global scope and is much safer
  } finally {
    window.System = backupSystem;
 }
};

// copy s.js to here

self.System.constructor.prototype.shouldFetch = function () { return true; };
window.MySystemJS = self; // or maybe `window.MySystemJS = self.System` to be a little simpler

})();

Can add a fetch polyfill too if needed. Loaded scripts need to be samesite or CORS enabled.

[halostatue]

Thank you. You can assume that I have a rant that I don’t want to have to think about any of this stuff, just be able to deploy and have it work without conflicts. It doesn't help that the client is on an ancient version of SystemJS that does not work like modern versions of SystemJS at all, so I think that I was always going to end up having to do something … "unsafe" like this.

I'll see if I can do some text-replace magic in the bundles &c. to see if the concept will work and try from there.