Dynamic ES module loader

Last update: Dec 29, 2022

Related tags

Overview

SystemJS

SystemJS is a hookable, standards-based module loader. It provides a workflow where code written for production workflows of native ES modules in browsers (like Rollup code-splitting builds), can be transpiled to the System.register module format to work in older browsers that don't support native modules, running almost-native module speeds while supporting top-level await, dynamic import, circular references and live bindings, import.meta.url, module types, import maps, integrity and Content Security Policy with compatibility in older browsers back to IE11.

Backers

Thank you to all our backers! 🙏 [Become a backer]

Overview

1. s.js minimal production loader

The minimal 2.8KB s.js production loader includes the following features:

Loads System.register modules, the CSP-compatible SystemJS module format.
Support for loading bare specifier names with import maps via <script type="systemjs-importmap">.
Supports hooks for loader customization.

2. system.js loader

The 4.2KB system.js loader adds the following features in addition to the s.js features above:

Tracing hooks and registry deletion API for reloading workflows.
Supports loading Wasm, CSS and JSON module types.
Includes the global loading extra for loading global scripts, useful for loading library dependencies traditionally loaded with script tags.

3. system-node.cjs loader

The system-node.cjs loader is a version of SystemJS build designed to run in Node.js, typically for workflows where System modules need to be executed on the server like SSR. It has the following features:

Loading System modules from disk (via file:// urls) or the network, with included caching that respects the Content-Type header.
Import Maps (via the applyImportMap api).
Tracing hooks and registry deletion API for reloading workflows.
Loading global modules with the included global loading extra.

Loading CommonJS modules is not currently supported in this loader and likely won't be. If you find you need them it is more advisable to use Node.js native module support where possible instead of the SystemJS Node.js loader.

Extras

The following pluggable extras can be dropped in with either the s.js or system.js loader:

AMD loading support (through Window.define which is created).
Named register supports System.register('name', ...) named bundles which can then be imported as System.import('name') (as well as AMD named define support)
Dynamic import maps support. This is currently a potential new standard feature.

The following extras are included in system.js loader by default, and can be added to the s.js loader for a smaller tailored footprint:

Global loading support for loading global scripts and detecting the defined global as the default export. Useful for loading common library scripts from CDN like System.import('//unpkg.com/lodash').
Module Types .css, .wasm, .json module type loading support in line with the existing modules specifications.

Since all loader features are hookable, custom extensions can be easily made following the same approach as the bundled extras. See the hooks documentation for more information.

SystemJS Babel

To support easy loading of TypeScript or ES modules in development SystemJS workflows, see the SystemJS Babel Extension.

SystemJS does not support direct integration with the native ES module browser loader because there is no way to share dependencies between the module systems. For extending the functionality of the native module loader in browsers, see ES module Shims, which like SystemJS, provides workflows for import maps and other modules features, but on top of base-level modules support in browsers, which it does using a fast Wasm-based source rewriting to remap module specifiers.

Performance

SystemJS is designed for production modules performance roughly only around a factor of 1.5 times the speed of native ES modules, as seen in the following performance benchmark, which was run by loading 426 javascript modules (all of @babel/core) on a Macbook pro with fast wifi internet connection. Each test was the average of five page loads in Chrome 80.

Tool	Uncached	Cached
Native modules	1668ms	49ms
SystemJS	2334ms	81ms
es-module-shims	2671ms	602ms

Getting Started

Introduction video.

The systemjs-examples repo contains a variety of examples demonstrating how to use SystemJS.

Installation

npm install systemjs

Documentation

Example Usage

Loading a System.register module

You can load System.register modules with a script element in your HTML:

<script src="system.js"></script>
<script type="systemjs-module" src="/js/main.js"></script>
<script type="systemjs-module" src="import:name-of-module"></script>

Loading with System.import

You can also dynamically load modules at any time with System.import():

System.import('/js/main.js');

where main.js is a module available in the System.register module format.

Bundling workflow

For an example of a bundling workflow, see the Rollup Code Splitting starter project - https://github.com/rollup/rollup-starter-code-splitting.

Note that when building System modules you typically want to ensure anonymous System.register statements like:

System.register([], function () { ... });

are emitted, as these can be loaded in a way that behaves the same as normal ES modules, and not named register statements like:

System.register('name', [], function () { ... });

While these can be supported with the named register extension, this approach is typically not recommended for modern modules workflows.

Import Maps

Say main.js depends on loading 'lodash', then we can define an import map:

<script src="system.js"></script>
<script type="systemjs-importmap">
{
  "imports": {
    "lodash": "https://unpkg.com/[email protected]/lodash.js"
  }
}
</script>
<!-- Alternatively:
<script type="systemjs-importmap" src="path/to/map.json" crossorigin="anonymous"></script>
-->
<script type="systemjs-module" src="/js/main.js"></script>

IE11 Support

IE11 continues to be fully supported, provided the relevant polyfills are available.

The main required polyfill is a Promise polyfill. If using import maps a fetch polyfill is also needed.

Both of these can be loaded conditionally using for example using Bluebird Promises and the GitHub Fetch Polyfill over Unpkg:

<script>
  if (typeof Promise === 'undefined')
    document.write('<script src="https://unpkg.com/[email protected]/js/browser/bluebird.core.min.js"><\/script>');
  if (typeof fetch === 'undefined')
    document.write('<script src="https://unpkg.com/[email protected]/dist/fetch.umd.js"><\/script>');
</script>

located before the SystemJS script itself. The above will ensure these polyfills are only fetched for older browsers without Promise and fetch support.

Note on Import Maps Support in IE11

When using external import maps (those with src="" attributes), there is an IE11-specific workaround that might need to be used. Browsers should not make a network request when they see <script type="systemjs-importmap" src="/importmap.json"></script> during parsing of the initial HTML page. However, IE11 does so. Codesandbox demonstration

Normally this is not an issue, as SystemJS will make an additional request via fetch/xhr for the import map. However, a problem can occur when the file is cached after the first request, since the first request caused by IE11 does not send the Origin request header by default. If the request requires CORS, the lack of an Origin request header causes many web servers (including AWS Cloudfront) to omit the response CORS headers. This can result in the resource being cached without CORS headers, which causes the later SystemJS fetch() to fail because of CORS checks.

This can be worked around by adding crossorigin="anonymous" as an attribute to the <script type="systemjs-importmap"> script.

Community Projects

A list of projects that use or work with SystemJS in providing modular browser workflows. Post a PR.

es-dev-server - A web server for developing without a build step.
import map overrides - Dynamically inject an import map stored in local storage so that you can override the URL for any module. Can be useful for running development modules on localhost against the server.
js-env - Collection of development tools providing a unified workflow to write JavaScript for the web, node.js or both at the same time.
jspm.org - Package manager for native modules, using SystemJS for backwards compatibility.
single-spa - JavaScript framework for front-end microservices.
systemjs-webpack-interop - npm lib for setting webpack public path and creating webpack configs that work well with SystemJS.
esm-bundle - list of System.register versions for major libraries, including documentation on how to create a System.register bundle for any npm package.

Compatibility with Webpack

Code-splitting builds on top of native ES modules, like Rollup offers, are an alternative to the Webpack-style chunking approach - offering a way to utilize the native module loader for loading shared and dynamic chunks instead of using a custom registry and loader as Webpack bundles include. Scope-level optimizations can be performed on ES modules when they are combined, while ensuring no duplicate code is loaded through dynamic loading and code-sharing in the module registry, using the features of the native module loader and its dynamic runtime nature.

systemjs-webpack-interop is a community-maintained npm library that might help you get webpack and systemjs working well together.

As of [email protected], it is now possible to compile webpack bundles to System.register format, by modifying your webpack config:

{
  output: {
    libraryTarget: 'system', 
  }
}

If using webpack@<5, the following config is needed to avoid rewriting references to the global System variable:

{
  module: {
    rules: [
      { parser: { system: false } }
    ]
  }
}

Using npm packages

Third party libraries and npm packages may be used as long as they are published in a supported module format. For packages that do not exist in a supported module format, here is a list of github repos that publish System.register versions of popular third party libraries (such as react, react-dom, rxjs, etc).

Contributing to SystemJS

Project bug fixes and changes are welcome for discussion, provided the project footprint remains minimal.

To run the tests:

npm run build && npm run test

Changes

For the changelog, see CHANGELOG.md.

License

MIT

Comments

Conditional proposal
Here's a variation that captures the previous features of conditionals (https://github.com/systemjs/systemjs/pull/189, https://github.com/systemjs/systemjs/issues/126), but is much less verbose:

System.sites = { // in this case the `./detect/browser/name.js` module has `export default browserName` // which is a string, that then gets used as a conditional wildcard in the mapping 'browserName': './detect/browser/name.js', 'browser/feature.js': '/some/package/#{browserName}/feature.js' }

Conditionals would be equally possible to set through paths and map, and work in imports as they are the final normalize action before plugins.

The symbol is #{...} which acts by simple string replacement. Alternative suggestions to # welcome.

Please give feedback! This is the most terrifying API I've ever designed.
opened by guybedford 58
An option to load modules from node_modules
I'd like to have an option to load npm modules from node_modules folder. I think there maybe could be some config option called npmModules. If it equals to true then required path that doesn't include path chars (dots and slashes) require modules from node_modules:

import module from 'module'; // loads node_modules/module/somescript.js

import module from './module'; // loads basePath/module.js

Besides the option bowerOption could load bower modules.

Thanks
support
opened by finom 52
Gist endpoint?

gist.github.com can be used as a place for storing individual modules (or other types of file) as opposed to packages stored in github repos, so I'm thinking it might be useful to have this as an endpoint?

opened by probins 51
Cache Busting Extension

Related from https://github.com/bitovi/steal/issues/129, would you consider adding a cache-busting extension to SystemJS? This would allow someone to specify a build number and every URL would include a ?buildNumber=123123 to make sure nothing would be cached.

Note: We added this to StealJS as cacheVersion.

discussion

opened by justinbmeyer 45
How to load Vue 3
SystemJS Version: 6.7.1

Which library are you using?

[x] 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? Yes - the ESM extra in https://github.com/systemjs/systemjs/pull/2187

Question

Vue 3 no longer publishes a UMD build. Instead, it publishes CJS, global, and ESM builds. Unfortunately, the global build creates multiple global variables - one for Vue and one for its devtools - and SystemJS selects the wrong global variable when determining which one to use as the module. See line 7826 of https://unpkg.com/browse/[email protected]/dist/vue.runtime.global.js for where the devtools global variable is created.

The only way I'm able to load Vue 3 now is to load the ESM build of Vue, and then use a modified version of SystemJS and the esm custom extra shown in https://github.com/systemjs/systemjs/pull/2187. This code sandbox shows that that extra works.

I think being able to load Vue 3 is pretty important - do you have thoughts on best way to do so without having to use a modified version of SystemJS?
opened by joeldenning 41
WASM memory registration
When using an ES-modules-style linking with WASM there is a need for more than just blind ES linking, but an actual memory referencing protocol to be able to handle the standard use cases.

By default, LLVM compilation of Web Assembly (or the s2wast transform?) will make the memory exported, and will load external functions from an env module.

The idea here for SystemJS is to check if there is an env import for the WASM module being loaded, and if so, to have that env module generated at link time to bind to the memory via something like:

let envModule = generateWasmEnv(wasmMemory);

This core env wasm handler to be customized via System.config({ wasmEnv: 'x.js' }).

An example WASM environment loader might look like:

export default function generateWasmEnv (wasmMemory) { return { malloc (size) { // ... malloc implementation bound to memory now ... }, // ... stdlib helpers ... }; }

It may even be possible to read the imports and provide the list of env imports specifically to the generation function.

Where the WASM module need only call malloc(size) to get the memory automatically referenced by the bound env file call.

Such a feature should be opt-in only as it is highly experimental.

//cc @lukewagner @yuridelendik would value your feedback / experience / suggestions here. And also to know if this is completely crazy or something that might be worth prototyping here.
opened by guybedford 40
Loading pure typescript packages
Hi, I am writing a package that I want to keep in pure TypeScript. The problem is that while it works well to load TypeScript files locally using package and defaultExtension, it becomes a different matter when I create a package and then install it using jspm.

Because then it feels like I lose control, specifying package extensions like this:

packages: { "jspm_packages/github/OptimalBPM/mbe-nodes*": { "defaultExtension": "ts" } }

And "jspm_packages/github/OptimalBPM/[email protected]" or any other combinations I have tried doesn't help. It keeps trying to load the .ts.js either way.

NOTE: I am working against a local registry.
opened by nicklasb 39
In-browser transpilation sourcemaps do not work outside of Chrome

When we load our scripts from internet explorer (any version including IE 11) source maps are not being loaded. (Where as chrome loads them properly in my case) The issue is documented here as well: http://colinsalmcorner.com/post/aurelia--debugging-from-within-visual-studio and he suggests using require.js as a work around. Please fix it.
contributions wanted

opened by OnurGumus 39
ESM Extra
Summary

This PR introduces an extra that adds support for loading ESM files via System.import().

Issue: https://github.com/systemjs/systemjs/issues/2013 Demo: Codepen

Motivation

ESM via script tag is supported by 90.36% of user browsers and import() is supported by 87.81%. Although we're starting to see increased adoption amongst packages (eg. lodash-es, Vue 3), it falls short on supporting import-maps.

With this extra, SystemJS can add introductory import-map support for bridging non-ESM to ESM, by allowing non-ESM files to import specifiers that resolve to ESM. This could open an incremental migration path to ESM.

Technical details

How does it work? This extra hooks into SystemJS#instantiate to use native dynamic-import (import()) to load ESMs.

Subsequent imports in ESM are done natively instead of through SystemJS, so import-maps will not be respected beyond non-ESM code.

Why doesn't it use <script type="module"> instead? As mentioned, there doesn't seem to be an easy way to fetch the export value of an anonymous script-module.

If we want an approach that uses a script-module, we can consider creating a global callback and an ESM import registry to mount an anonymous script-module like this:

<script type="module"> import * as exported from '${url}'; callback('${url}', exported); </script>

Seemed to add a lot more complexity than using import(), but if we're worried about browser support, we can also require es-module-shims as it basically does that to shim dynamic import.

What browsers does it support? I'm thinking this extra should be light and only aim at bridging non-ESM to ESM. That's to say, it would only work with newer browsers out-of-the-box. IE won't be supported a but perhaps older versions of Edge can be supported by detecting whether es-module-shims has been loaded by checking for importShim.

How can import maps be supported in ESM? Based on the conversation here, it would require transformations to convert native import statements to use SystemJS. es-module-shims seems to handle that for you, but reads a different import-map from SystemJS. Perhaps the import-map selector can be made to be configurable.

cc @guybedford

How will it determine whether to use import or SystemJS's default script-load? It currently checks whether a URL path matches the regex pattern \besm\b. That way, it could catch package names or file names with esm in it, but also supports URLs that doesn't have esm in it if the user adds the hash #esm (?esm sends a server query). eg.

<script type="systemjs-importmap"> { "imports": { "axios": "https://cdn.pika.dev/axios#esm" } } </script>

I don't think this is the best approach so I'm interested to hear alternatives. Perhaps strictly checking for #esm would be a safer approach.

Remaining work

[ ] Add tests
opened by privatenumber 38
CommonJS compatibility

I noticed the CommonJS extension returns globals.module.exports in the instantiate hook. This means properties of module.exports will be named exports of the imported module. However, this breaks the CommonJS semantics in favor of ES6's. Shouldn't it instead be returning { default: globals.module.exports }?

opened by juandopazo 38
What's the plan/status/roadmap?

I'm confused. (Frankly, I'm mindboggled.)

I have spent hours reading conflicting blog-posts, stack-overflow answers and various specifications, and I have no idea what's happening, where this project is going, or even what precisely this project is.

Okay, so the front page of your README says:

Built to the format ES6-specified loader API from ES6 Specification Draft Rev 27, Section 15

Well, that draft is over two years old.

There have been more than 10 updates to that specification since.

More recent versions of the specification don't even seem to have the part of the specification you're referencing?

The most recent update to that specification was the last of a series of four release candidates, but it's more than a year-and-a-half old - there was never a final release, so this looks to be dead in the water and never officially released?

The README continues:

and will be updated to the WhatWG loader API as soon as it can be considered stable for implementation.

Okay, so I'm looking at that.

It doesn't seem to specify anything called System.register(), so what is this? Is it supposed to supersede and replace the other specification? How will that affect what this package is or does, and will it even be the same thing at all once it gets updated to this specification?

I keep hearing AMD is a "receding" module format. But then I look at popular packages such as JQuery, and it doesn't even seems to support System.register() at all. I understand that this loader supports other package formats as well, so of course it will load JQuery - what I don't understand is, if this new System API is "the future" in terms of ES6 support on the client-side and so on, how come practically no major packages even support it yet?

I understand we'll need polyfills for all these other module formats (ugh) at least for a while, but I'd like to envision a future where, eventually, the System API is the standard for loaders, and we can finally use something clean and small like the es6-micro-loader and drop support for all these other dated module formats. That's the end game, right? I don't want to think that this is just yet another module format to add to the list, but will that happen, or why isn't it?

Why aren't even major packages like JQuery supporting it yet?

What's the status of these specifications and where is this project going?

(I apologize for the rant. I'm sure this may be entirely the wrong place to ask. If so, I apologize, and can you please point me to the right place to ask? Or point me to the right, preferably official source for current, correct information about these matters?)

opened by mindplay-dk 32
Can the latest version 6.13.0 completely replace version 0.21?
SystemJS Version: 0.21

Which library are you using?

systemjs/dist/system.src.js

The babel in systemjs-plugin-babel of SystemJS 0.21 is too old to handle ?. syntax. So I want to upgrade SystemJS to 6.13.0. Can the latest version 6.13.0 completely replace version 0.21? I am confused that [Loads any module format], which was one of the most important promotional points in the old version, is missing in the latest version. And it seems version 6.13.0 doesn't support AMD require and CommonJS Module.

Question

Can the new api completely replace the old config-api? Is it possible to have an example document showing how to convert from the old config-api to the new api?

Chutzpah still uses the old config-api, has the new version not been widely accepted yet?

Is this project still committed to loading any module format? Are there plans to fully support AMD and CommonJS Module?

I also tried updating the version of the babel of systemjs-plugin-babel of SystemJS 0.21. That is, build a new systemjs-plugin-babel with the latest @babel/[email protected]. The disappointing thing is that the jspm 0.17.0-beta.49, which used to build also uses old version' SystemJS, systemjs-plugin-babel and babel, failed to build @babel/[email protected]. It can't handle some of the new syntax in @babel/[email protected]. Is there a way to do the babel upgrading?

I will really appreciate your help. Regards!
opened by V-MI 0
Cannot make React 18 (production, UMD) work with SystemJS
SystemJS Version: 6.13.0

Which library are you using?

[X] 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?

Question

I created a test repository: https://github.com/noherczeg/system-react where I wanted to play around with React 18 + SystemJS, but cannot make it work.

One of the main problems is that React moved away from the old jsx-runtime, and now it relies on compile-time magic in traditional (CJS-ish?) environments.

The current state of the demo repo produces "react-dom.production.min.js:218 Uncaught TypeError: Cannot read properties of undefined (reading '__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED')".

It is IMPORTANT to note, that our aim is to use the production version of both React and React DOM!

I have identified two options which I could play with:

Comment out commonjs(), and nodeResolve() in the rollup configs

Remove the external section from the Rollup config.

In the first scenario I get a runtime error of: "Uncaught (in promise) Error: Unable to resolve bare specifier 'react/jsx-runtime' from http://localhost:3000/index.js"

After this I "redundantly" added the following to the import map:

{ "imports": { // other stuff which I didn't touch "react/jsx-runtime": "./[email protected]/umd/react.production.min.js", "react-dom/client": "./[email protected]/umd/react-dom.production.min.js" } }

But then I get these errors:

"Uncaught TypeError: Cannot read properties of undefined (reading '__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED')"

"material-ui.production.min.js:6 Uncaught TypeError: Cannot read properties of undefined (reading 'useLayoutEffect')"

(The second error comes from MUI)

This must be super simple to set up, but I spent 4 hours with this topic without success, can anyone please help me out?

Thanks, Norbert
opened by noherczeg 4

System.import() is deprecated and will be removed soon. Use import() instead.

Hi! 👋

Firstly, thanks for your work on this project! 🙂

Today I used patch-package to patch [email protected] for the project I'm working on.

Here is the diff that solved my problem:

diff --git a/node_modules/systemjs/dist/system.js b/node_modules/systemjs/dist/system.js
index 1cbf2ba..7f0bb75 100644
--- a/node_modules/systemjs/dist/system.js
+++ b/node_modules/systemjs/dist/system.js
@@ -529,7 +529,7 @@
         script.sp = true;
         if (!script.src)
           return;
-        System.import(script.src.slice(0, 7) === 'import:' ? script.src.slice(7) : resolveUrl(script.src, baseUrl)).catch(function (e) {
+          envGlobal.System.import(script.src.slice(0, 7) === 'import:' ? script.src.slice(7) : resolveUrl(script.src, baseUrl)).catch(function (e) {
           // if there is a script load error, dispatch an "error" event
           // on the script tag.
           if (e.message.indexOf('https://git.io/JvFET#3') > -1) {

This issue body was partially generated by patch-package.

opened by wangshuqing 0

system.import() is deprecated and will be removed soon. use import() instead

SystemJS Version: 6.13.0

Question

When I use systemjs When importing, 'system import() is deprecated and will be removed soon. use import() instead'。 The compiling environment is webpack+vue2+ts

opened by J-DuYa 0
Uncaught (in promise) TypeError: r[1] is not a function

Demonstration

Code Sandbox:

Expected Behavior

I am serving a local library lib successfully and want to consume it in my root-app via systemjs-importmap as shared dependency. (libraryTarget: "system")

Actual Behavior

I am getting an Uncaught (in promise) TypeError: r[1] is not a function

opened by thanosoncode 0

Releases(6.13.0)

6.13.0(Sep 29, 2022)
What's Changed

avoid module-types override shouldFetch by @wenerme in https://github.com/systemjs/systemjs/pull/2427

expose addImportMap by @wenerme in https://github.com/systemjs/systemjs/pull/2429

add community project @wener/system by @wenerme in https://github.com/systemjs/systemjs/pull/2430

New Contributors

@wenerme made their first contribution in https://github.com/systemjs/systemjs/pull/2427

Full Changelog: https://github.com/systemjs/systemjs/compare/6.12.6...6.13.0
Source code(tar.gz)
Source code(zip)
6.12.3(Aug 18, 2022)
What's Changed

test: fix typo in chompfile.toml by @nilzona in https://github.com/systemjs/systemjs/pull/2413

fix: build source maps by @guybedford in https://github.com/systemjs/systemjs/pull/2416

New Contributors

@nilzona made their first contribution in https://github.com/systemjs/systemjs/pull/2413

Full Changelog: https://github.com/systemjs/systemjs/compare/6.12.2...6.12.3
Source code(tar.gz)
Source code(zip)
6.12.2(Aug 10, 2022)
What's Changed

feat: Chomp migration, windows build, GitHub CI by @guybedford in https://github.com/systemjs/systemjs/pull/2405

ci: fixup size impact script by @guybedford in https://github.com/systemjs/systemjs/pull/2406

ci: fix size impact script Node.js version by @guybedford in https://github.com/systemjs/systemjs/pull/2407

Fix a concurrent bug due to async execution by @shrinktofit in https://github.com/systemjs/systemjs/pull/2404

refactor: replace all git.io within the error message by @SukkaW in https://github.com/systemjs/systemjs/pull/2390

New Contributors

@shrinktofit made their first contribution in https://github.com/systemjs/systemjs/pull/2404

@SukkaW made their first contribution in https://github.com/systemjs/systemjs/pull/2390

Full Changelog: https://github.com/systemjs/systemjs/compare/6.12.1...6.12.2
Source code(tar.gz)
Source code(zip)
6.12.1(Jan 21, 2022)
Features

Call fetch hook when retrieving external import maps. Resolves #2374. by @joeldenning in https://github.com/systemjs/systemjs/pull/2376

Full Changelog: https://github.com/systemjs/systemjs/compare/6.11.0...6.12.1
Source code(tar.gz)
Source code(zip)
6.11.0(Oct 18, 2021)
Features

Allow createScript hook to return a promise. (#2362 via @legarsjules)

Patches

Use Promse.resolve in named register. Resolves #2359 (#2363)

Source code(tar.gz)
Source code(zip)
6.10.3(Aug 17, 2021)
Fixes

Avoid double instantiation of named registers. (https://github.com/systemjs/systemjs/pull/2352)

Always return the first named register from a file. (https://github.com/systemjs/systemjs/pull/2352)

Source code(tar.gz)
Source code(zip)
6.10.2(Jul 4, 2021)
Patches

Fix warning with node 16 (#2347 @JJ)

Source code(tar.gz)
Source code(zip)
6.10.1(Jul 4, 2021)
Patches

fixup module types browser check (#2343)

Source code(tar.gz)
Source code(zip)
6.10.0(Jun 7, 2021)
Features

Refactor amd.js to only call System.register. Resolves #2331. Add Error #9 and Warning W6 to errors.md documentation. This is a significant refactor but should not change behavior. (#2335)

Add package.json to package exports (https://github.com/systemjs/systemjs/pull/2317 @mk-pmb)

Patches

Do not throw errors when _export(null) is called. Resolves #2332. (#2334)

Source code(tar.gz)
Source code(zip)
6.9.0(May 12, 2021)
Features

Onerror Callback Support for Errors Fetching External Import Map (https://github.com/systemjs/systemjs/pull/2324 @kykwak)

Fix the relative path problem of CSS url() in CSSStyleSheet() (https://github.com/systemjs/systemjs/pull/2326 @liufei)

Patches

Fix named-register.js - omit name from register call. Resolves #2293. (https://github.com/systemjs/systemjs/pull/2329 @joeldenning)

Docs

Fixed importmap example code (https://github.com/systemjs/systemjs/pull/2309 @maurer2)

Source code(tar.gz)
Source code(zip)
6.8.3(Dec 31, 2020)
Patches

Allow deletion of uninstantiated modules whose top level parent import finished. (https://github.com/systemjs/systemjs/pull/2291)

Source code(tar.gz)
Source code(zip)
v6.8.2(Dec 16, 2020)
Patches

Fix deleting modules after link failure. Resolves #2286. (https://github.com/systemjs/systemjs/pull/2288)

Ensure onload hooks retain catches (https://github.com/systemjs/systemjs/pull/2289)

Footprint improvement for browser (https://github.com/systemjs/systemjs/pull/2290)

Source code(tar.gz)
Source code(zip)
6.8.0(Nov 26, 2020)
Features

System.firstGlobalProp for global loading extra (https://github.com/systemjs/systemjs/commit/48351aa83c48fdd22b63000d417dedc2329f2340, @joeldenning)

Graceful import map loading errors (https://github.com/systemjs/systemjs/commit/9edebd1969842dcc95a12d4137677c6bc9fe2bae, @naltatis)

Sourcemap normalization for fetch loader (https://github.com/systemjs/systemjs/commit/97621d724cc7c892d9dee2cff6b27553326c8169)

Dispatch script loading errors for <script type="systemjs-module"> (https://github.com/systemjs/systemjs/commit/f0fe5a473414b995082688c30a876c602e32d901, @dmail)

Source code(tar.gz)
Source code(zip)
6.7.1(Oct 12, 2020)
Fix auto import race condition (https://github.com/systemjs/systemjs/commit/5f0cf3a77717b012ce14812327fd7ea531e0436e)

Source code(tar.gz)
Source code(zip)
6.7.0(Oct 9, 2020)
Features & Deprecations

Implement integrity attribute for systemjs-importmap scripts (https://github.com/systemjs/systemjs/commit/78072e594ebebab9124aa9fedd7e17d8303835e1)

Deprecate the transform and use default extras (https://github.com/systemjs/systemjs/commit/5f7571a76bef210d096e672c9f011d94871a6827)

Fetch hooks brought into core, module types extra refactoring (https://github.com/systemjs/systemjs/commit/281fdf0653663c58145f880131dceaf479add553)

Deprecate the named exports extra bringing its behaviours into core (https://github.com/systemjs/systemjs/commit/3eefa2daa8d203e8d886bae7dc587eed148c5808)

Source code(tar.gz)
Source code(zip)
6.6.1(Sep 12, 2020)
Bug Fixes

Fix IE11 support (https://github.com/systemjs/systemjs/pull/2247)

Source code(tar.gz)
Source code(zip)
6.6.0(Sep 12, 2020)
Features

Set "type": "script" in package.json (https://github.com/systemjs/systemjs/pull/2246)

Bug Fixes

Fix autoimport dynamic import conflicts (https://github.com/systemjs/systemjs/pull/2245)

Source code(tar.gz)
Source code(zip)
6.5.1(Sep 2, 2020)
Patches

Fix depcache hook (https://github.com/systemjs/systemjs/pull/2242)

Source code(tar.gz)
Source code(zip)
6.5.0(Aug 10, 2020)
Features

import.meta.resolve implementation (https://github.com/systemjs/systemjs/pull/2230)

Import maps integrity feature (https://github.com/systemjs/systemjs/pull/2229)

Source code(tar.gz)
Source code(zip)
6.4.3(Aug 6, 2020)
Features

Define an "s.js" entry in "exports" (https://github.com/systemjs/systemjs/pull/2226)

Patches

Fixup use of const for older browsers (https://github.com/systemjs/systemjs/issues/2227)

Source code(tar.gz)
Source code(zip)
6.4.2(Aug 5, 2020)
Patches

Fix and simplify auto import domready resets (https://github.com/systemjs/systemjs/pull/2225)

Source code(tar.gz)
Source code(zip)
6.4.1(Jul 31, 2020)
Patches

Fix auto import handling of dynamic import races during loading phase (https://github.com/systemjs/systemjs/pull/2223)

Fix crossOrigin script attribute loading in Safari (https://github.com/systemjs/systemjs/pull/2222)

Source code(tar.gz)
Source code(zip)
6.4.0(Jul 23, 2020)
Features

Dynamic import map extra support (https://github.com/systemjs/systemjs/pull/2217 @stevenvachon)

Depcache support in import maps for automated preloading (https://github.com/systemjs/systemjs/pull/2134)

Auto Import feature for <script src="system-register-module.js"> loading for better load performance (https://github.com/systemjs/systemjs/pull/2216, https://github.com/systemjs/systemjs/pull/2210 @tmsns)

Patches

Fix onload behaviour with flag for error source (https://github.com/systemjs/systemjs/pull/2204 @smartrejames)

Fix Object.prototype mutation (https://github.com/systemjs/systemjs/pull/2206 @stevenvachon)

Source code(tar.gz)
Source code(zip)
6.3.3(Jun 27, 2020)
Patches

Better error message when content-type header is missing (https://github.com/systemjs/systemjs/pull/2197 via @brandones)

Make setters optional (#2193 via @guybedford)

Source code(tar.gz)
Source code(zip)
6.3.2(May 18, 2020)
Patches

Named export extra now works with non-objects (#2186 via @Sauloxd)

Use correct error number for error 8 (https://github.com/systemjs/systemjs/pull/2182 via @guybedford)

Source code(tar.gz)
Source code(zip)
6.3.1(Apr 13, 2020)
Patches

Fix error code mixup (https://github.com/systemjs/systemjs/pull/2169)

Fix bug in system-node.cjs where prepareImport overwrote import map (https://github.com/systemjs/systemjs/pull/2170)

Adding full dist directory to package.json exports (https://github.com/systemjs/systemjs/pull/2173)

Increasing timeout for test:node script (https://github.com/systemjs/systemjs/pull/2174)

Switching to node-fetch to avoid caching bugs in make-fetch-happen (https://github.com/systemjs/systemjs/pull/2171)

Source code(tar.gz)
Source code(zip)
6.3.0(Apr 9, 2020)
Features

s.js now has full import map support (https://github.com/systemjs/systemjs/pull/2150)

New system-node.cjs loader designed to run in NodeJS. (https://github.com/systemjs/systemjs/pull/2150, https://github.com/systemjs/systemjs/pull/2158)

SystemJS now has error codes, along with documentation for each error code (https://github.com/systemjs/systemjs/pull/2151)

Patches

Fix bug in Chrome 45 where const/let disallowed unless in strict mode (https://github.com/systemjs/systemjs/pull/2162)

Add warning for calling System.set with non-URL id (https://github.com/systemjs/systemjs/pull/2161)

Maintenance

Upgrading dependencies and switching building of extras to rollup (https://github.com/systemjs/systemjs/pull/2149)

Add issue templates (https://github.com/systemjs/systemjs/pull/2157)

Add bot for bundle size changes to pull requests (https://github.com/systemjs/systemjs/pull/2156, https://github.com/systemjs/systemjs/pull/2166)

Running tests in Travis CI, including browser tests (https://github.com/systemjs/systemjs/pull/2160)

Documentation for system-node.cjs (https://github.com/systemjs/systemjs/pull/2164, https://github.com/systemjs/systemjs/pull/2168)

Fixing tests in IE11 (https://github.com/systemjs/systemjs/pull/2167)

Source code(tar.gz)
Source code(zip)
6.2.6(Mar 15, 2020)
Patches

Fix for named register race conditions with firstNamedDefine (https://github.com/systemjs/systemjs/pull/2144, resolves https://github.com/systemjs/systemjs/issues/2139 and https://github.com/systemjs/systemjs/issues/2138)

Source code(tar.gz)
Source code(zip)
6.2.5(Feb 27, 2020)
Patches

Fix problem where a falsy exported value from AMD modules didn't work (https://github.com/systemjs/systemjs/pull/2130 via @lpomerleau)

Source code(tar.gz)
Source code(zip)
6.2.4(Feb 24, 2020)
Patches

Fix problem where System.delete did not remove named register modules. Now named register modules are automatically removed from registerRegistry as soon as they are used once. (https://github.com/systemjs/systemjs/pull/2125 @k-j-kim)

Source code(tar.gz)
Source code(zip)