Module "Shimming"

Jacob Gable jacob.gable at
Tue Apr 1 11:08:36 PDT 2014

I was wondering if anyone has any thoughts/approaches on shimming non ES6
modules.  I've run into two different approaches so far and there doesn't
seem to be much guidance around the process.

To be clear, all I'm talking about right now is what to do about libraries
like jQuery or Backbone that are not ES6 modules (yet).  What I've done so
far is to rely on all my vendor libraries being on the page first and then
creating a single libraries "shim" file that just exports whatever
libraries are on the global/window namespace.

// File: vendor/libraries.js

var globals = globals || window;

export var $ = globals.jQuery;
export var _ = globals._;
export var underscore = globals._;
export var Backbone = globals.Backbone;

Then these are imported from our other modules like so:

// File: views/foo.js

import { _, Backbone } from 'vendor/libraries';

export default Backbone.View.extend({ ... });

In other places like ember-cli and ember-app-kit I've seen a reliance on
the transpilation process to AMD format that assumes an `import foo from
'ember-qunit';` call is going to work when transpiled to `var foo =
require('ember-qunit');`, but that seems like mixing module implementations.

Finally, my real question is, can I achieve a "shimming" system like
requirejs ( has through the
creation of a custom Loader?  It seems like the Instantiate method could be
overridden to potentially achieve something like this?  It would evaluate
the code, then export the window.jQuery value as the instantiated module?
 Functionality like this would be ideal for us since we would then be able
to only include the necessary vendor libraries on the page through imports
instead of making sure all were on the page already (or making page
specific vendor script builds).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list