Coexistence with native import maps

[oravecz-jpmc]

• SystemJS Version: 6.15.1
• Which library are you using?
  • system.js
  • s.js
  • system-node.cjs
• Which extras are you using?
  • AMD extra
  • Named Exports
  • Named Register
  • Transform
  • Use Default
  • Global
  • Dynamic Import Maps
• Are you using any custom hooks?

Preferred way to coexist with native import maps

I have a host application built using React in the standard manner of bundling React along with the application. This happens to be bundled using Webpack, but I expect the behavior is the same with other bundlers.

In this application, there are some components exposed as native ESM packages, and others that are exposed as both native ESM and as System.register(). They are all loaded dynamically at runtime based on URL's provided by a service call (i.e. unknown at build time).

I've been having a difficult time trying to get these components to share an instance of React which is required for host-level communication and context sharing. I did stumble across mention of this in a @guybedford post, but with a caveat that this should not be done?

index.html

    <script type="importmap">
        {
            "imports": {
                "react": "/inbrowser/esm/react.production.min.js",
                "react-dom": "/inbrowser/esm/react-dom.production.min.js",
                "react/jsx-runtime": "/inbrowser/esm/react-jsx-runtime.production.min.js",
                ...other_shared_libraries
            }
        }
    </script>
    <script type="systemjs-importmap">
        {
            "imports": {
                "react": "app:react",
                "react-dom": "app:react-dom",
                "react/jsx-runtime": "app:react/jsx-runtime",
                ...other_shared_libraries
            }
        }
    </script>

index.tsx

import * as React from 'react';
import * as ReactDOM from 'react-dom';
import * as JsxRuntime from 'react/jsx-runtime';

import 'systemjs';
System.set('app:react', React);
System.set('app:react-dom', ReactDOM);
System.set('app:react/jsx-runtime', JsxRuntime);

This works for me, but I'm not sure what edge cases exist. I am not worried about backwards compatibility with browsers pre-2023 that do not support native import maps, but I do want some of the enhanced features such as external import map fetching and dynamic import map features.

I'm also unclear as to how SystemJS is sometimes referred to as a polyfill. In my attempts, all shared dependencies and the remote component I am loading have to be bundled using the System.register() format which requires an invasive step into all of these libraries.

When I attempt to System.import('/path/to/esm'), I receive the Cannot use import statement outside a module exception.

Would I be better served to use the es-module-shims package for my particular use case?

[internettrans]

Mixing SystemJS and native ES modules isn't something I'd recommend - complicated to debug. In the code you shared, one edge case to consider is whether the System.set() calls will execute before any code that attempts to load the module. Also, the systemjs module registry usually has fully resolved urls, rather than entries like app:react. I'd recommend adding a url to the systemjs import map for react and react-dom, then calling System.set(System.resolve('react'), React) rather than System.set('app:react', React).

I'm also unclear as to how SystemJS is sometimes referred to as a polyfill

SystemJS is not a polyfill, since native ES modules are not polyfillable in browsers that don't support them. However, it is polyfill-like, in that it provides a way to have native ES module semantics (default exports, live bindings, circular dependencies, etc) in browsers that don't support them.

When I attempt to System.import('/path/to/esm'), I receive the Cannot use import statement outside a module exception.

This is because systemjs appends a <script> tag rather than a <script type=module> script tag, when loading modules.

Would I be better served to use the es-module-shims package for my particular use case?

I recommend using native import maps rather than systemjs, especially for new projects. I use the import-map-injector library to support external import maps and multiple import maps, rather than es-module-shims. Depending on use case, native import maps without either of those libraries might be enough.

[oravecz-jpmc]

In my use case, we are transitioning from loading remote components via SystemJS and Module Federation to native imports, so the need to share the same instance of certain libraries is what is precipitating this question.

Currently, I am developing a Vite plugin where the use can specify the shared module (name and url to an ESM bundle), and I will generate the importmap for native imports, the systemjs-importmap for SystemJS and a module federation 2 hosting config. The basic idea is that each of these configurations are using the module instance loaded using native importmap.

The code I posted back in October seems to be working as expected, and I don't really understand the inner workings of SystemJS enough to fully grasp your suggested change to System.set(System.resolve('react'), React). You mentioned that you "recommend adding a url to the systemjs import map for react", but I don't understand why that wold matter in my particular use case. I don't have a url to a SystemJS-compatible (UMD or AMD) package of React, and I certainly don't want one to be used. Hence why I am using a simple substitute URL app:react instead.

I am wondering if I should avoid the static import of my modules and opt for a more dynamic loading. I'm concerned that the approach I am currently using doesn't return and make available the default export from the module. Perhaps changing to something like this is better than my initial code - and it seems to work just as well.

    <script type="importmap">
        {
            "imports": {
                "react": "https://esm.sh/react@18",
                "react-dom/": "https://esm.sh/react-dom@18/",
                "react/jsx-runtime": "https://esm.sh/react@18/jsx-runtime",
            }
        }
    </script>
    <script type="systemjs-importmap">
        {
            "imports": {
                "react": "app:react",
                "react-dom": "app:react-dom",
                "react/jsx-runtime": "app:react/jsx-runtime",
            }
        }
    </script>

import 'systemjs';

await Promise.all([
  import('react').then((module) => {
    System.set(`app:${'react'}`, module);
  }),
  import('react-dom').then((module) => {
    System.set(`app:${'react-dom'}`, module);
  }),
  import('react/jsx-runtime').then((module) => {
    System.set(`app:${'react/jsx-runtime'}`, module);
  }),
])
  .then(() => {
    console.log('SystemJS initialized');
  })
  .catch((err) => {
    console.error(err);
  });

[MattiasJa]

Hi,
I'm currently working on a project with a similar goal: migrating from SystemJS to native ImportMap/ESM. Since there are multiple design teams delivering various micro frontends, a "big bang" migration isn’t feasible. Ideally, SystemJS and native micro frontends should coexist for a while. Over time, as all teams set outputSystemJS: false and transition to native ImportMap, we can eventually remove SystemJS from the root config.

I'm following this thread because the plan is to start with shared packages, like React, and then gradually move to the more generic micro frontends (e.g., design system, header, etc.), eventually everything else. It would be great to hear some thoughts or suggestions!