Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slim Loader - Phase 1 #661

matthewp opened this Issue Apr 20, 2017 · 2 comments


None yet
1 participant
Copy link

matthewp commented Apr 20, 2017

This epic is the implementation of the minimal production loader RFC.

The loader needs to be able to:

  • Execute a bundle of JavaScript.
  • Progressively load JavaScript using some syntax (of our choosing) (maybe like steal.import).
  • Execute bundles loaded in any order (using script async).
  • Allow for some type of runtime plugins. This is mostly (and perhaps only) for CSS, so that's the target.

As code size is extremely important here, some guidelines for what we want to achieve:

  • The loader should not be any larger than the one provided by webpack.
  • The loader should be broken up by feature set to minimize size. For example there might be a loader.js that does the main loader stuff, and then a progressive.js which adds the ability to support steal.import, and then a plugin.js which adds the ability for plugins to exist. The build process would determine which features are needed and combine loader.js, progressive.js, and plugin.js.


As this is a rather large project this issue needs to be broken up into several tasks.


Sub-issues are being created for the loader, but the plan is:

  1. Create an internal api that can be used within steal-tools, maybe slim(options).
  2. Assume (at first) that it is a single main with no bundles. It should receive a bundle object, it will add a bundle before and after it (before is the loader shim, after is an end part).
  3. Allow more than 1 bundle to be passed in, this will mean that there's a split, so add more code to the shim to progressively load the non-main bundles.
  4. Allow an option like plugin: true. This will add the plugin capability to the loader. So things like the css plugin can do stuff.

Integrating with

This will happen second. There are a few parts here:

The challenge here is to figure out how to detect which features we do not support and to throw appropriate error messages. We cannot support:

  • Use of runtime configuration
  • Use of steal-specific modules like @loader or @steal. We can probably just hardcode these for now.

What the API looks like is not clear. It might be an option like:{}, { slim: true });

Or a separate API like:


Note, slim is the codename, it won't be used in the api, this is just for demonstration purposes.

No-closure mode

Not sure if this will be part of this epic or one to follow up, but if there is only 1 bundle, and it's a JavaScript bundle, we should be able to prevent all closures. The slim loader won't exist, just an IIFE that executes all of the bundles together (with their wrappers excluded). This is going to be a little tricky, you have to rewrite variable names so that they do not clash between modules.


This comment has been minimized.

Copy link
Member Author

matthewp commented Apr 20, 2017

Note that we should create a minor branch off of master and put changes into that branch.

@chasenlehara chasenlehara changed the title Slim Slim Loader May 12, 2017

@matthewp matthewp changed the title Slim Loader Slim Loader - Phase 1 Jun 1, 2017


This comment has been minimized.

Copy link
Member Author

matthewp commented Jun 30, 2017


@matthewp matthewp closed this Jun 30, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.