Discuss
  • Module "Shimming"

Module "Shimming"

# Jacob Gable (11 years ago)

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 (requirejs.org/docs/api.html#config-shim) 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).

# Rick Waldron (11 years ago)

Have you had a look at es6-module-transpiler? square/es6-module-transpiler it might be a good starting point for whatever you're trying to accomplish.

# John Barton (11 years ago)

On Tue, Apr 1, 2014 at 11:08 AM, Jacob Gable <jacob.gable at gmail.com> wrote:

...

Finally, my real question is, can I achieve a "shimming" system like requirejs (requirejs.org/docs/api.html#config-shim) 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).

IMO we should aim for having this feature in the standard Loader. Otherwise we are just going to go through incompatible custom loaders to achieve real work with es6 modules, defeating the very purpose of standardization.

jjb

# Guy Bedford (11 years ago)

On 1 April 2014 11:08, Jacob Gable <jacob.gable at gmail.com> wrote:

Finally, my real question is, can I achieve a "shimming" system like requirejs (requirejs.org/docs/api.html#config-shim) 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).

Yes exactly, the instantiate hook allows an identical shim system to be created.

So one can design a system something like -

System.shim['jquery'] = {
  exports: '$',
  deps: []
};

With System.import('jquery') then working correctly.