SystemJS (Registry) Target for Loader Spec

Creating SystemJS Registry Target for ES6 Loader Spec

Asside: This issue will be the tracker for our discussions and proposal with @guybedford after last weeks meeting. Since my explanation will not be as far as detailed as the discussions between @sokra and @guybedford, I will yield to them to fill in any details that I missed or got wrong.

Discussing the possibility of allowing, or making available public modules in webpack to be exposed for the System registry and loader.

This should be able to be done utilizing the same functionality from webpack’s DllPlugin in which chunk/moduleId’s are mapped to filenames per (@sokra). This will essentially provide a mapped context in which chunks can be loaded into the registry.

Configuring this will be an opt-in property that can be set with output.libraryTarget. Maybe the target name can be system? (Can discuss further).

Author: Fantashit

1 thought on “SystemJS (Registry) Target for Loader Spec

  1. I’ve made a start on this in

    This is by no means a completed project, but a starting point for further discussion.

    It works really nicely though, and allows any dynamic System.import to load webpack modules and dynamically load webpack chunks on demand.

    What it does

    We generate a manifest that selects webpack module ids to map to public names to be set in the loader registry via System.register or System.registerDynamic (ES module and CJS module registrations respectively). This manifest is included in the main output file, and any progressively loaded chunks also write into the registry as those chunks are loaded.

    We also provide the ability for automatically creating bundles configuration in SystemJS. What this means is that System.import('app/x') can load the correct webpack chunk for app/x assuming app/x is specified as a public module in this manifest.

    The manifest itself is generated through an array of filter, keyname pairs, which act as the “select” and “map” functions to create the manifest. These are explained in the README file. I tried to make this process as general as possible while still providing nice defaults so you can select any arbitrary modules and names to put into the registry.

    Questions / todos

    I still have a lot of ifs here, so feedback would be really welcome.

    1. Should we output the manifest as a sparse array or object (I tried to follow the webpack convention sort of here, but perhaps an object would make more sense?)
    2. We should have a better public module detection system based on whether the module is a main entry point or not. I’ve marked this sort of metadata as a todo in, the question then is how to populate this metadata in a way that is performant… we end up redoing a lot of the resolver work just to set those values (plus the constraint of this function being synchronous isn’t ideal).
    3. How to handle naming cases for eg lib/app/x.js where I want to name that mypublicName/x.js currently we compute a structured module object for template replacement ( but what is currently in place doesn’t seem to handle cases like this. API feedback on the keyname system would be welcome here. I think this is probably the most gritty and risky part of it. (the way to do this with the current API would be via something like keyname: (m) => m.relPath.replace(/^lib\/app\//, 'mypublicName/')
    4. Any ideas about how to handle caching for this are appreciated. I guess something like this is relatively cacheless, as it runs at a full compilation level and I don’t think it’s doing a lot of work anyway.
    5. Hot reloading is something else that can be added, I expect this will be straightforward actually, assuming we have hooks for the places where we’d need to remove and add modules into the SystemJS registry.

    Any questions further are very welcome, especially if there are gaps in the understanding of what this is doing.

    //cc @sokra @TheLarkInn @robwormald

Comments are closed.