Add global / package js! plugin configs to specify legacy options: exports and dependencies (like RequireJS's "shim config")

[unscriptable]

(Note: this feature would be the equivalent of RequireJS's shim options.)

Allow the following global or package-specific configs:

curl({
    plugins: {
        js: { 
            legacy: { // or "shim"
                backbone: { exports: 'Backbone', deps: ["jquery", "lodash"] }
            }
        }
    }
});

curl({
    packages: [
        { name: 'backbone', location: 'here/foo', main: '../backbone.min'
            config: {
                moduleLoader: 'curl/plugin/js',
                legacy: { exports: 'Backbone', deps: ["jquery", "lodash"] }
            }
        }
    ]
});

[unscriptable]

This may also work:

curl({
    paths: {
        backbone: { location: 'here/backbone.min.js', 
            config: {
                moduleLoader: 'curl/plugin/js',
                legacy: { exports: 'Backbone', deps: ["jquery", "lodash"] }
            }
        }
    }
});

[unscriptable]

We should implement this after #155 so we can use "transform" instead of "moduleLoader".

curl({
    paths: {
        backbone: { location: 'here/backbone.min.js', 
            transform: 'curl/plugin/js',
            config: { legacy: { exports: 'Backbone', deps: ["jquery", "lodash"] } }
        }
    }
});

[unscriptable]

@jaredcacurak @briancavalier @treasonx should we use the "legacy" name for this or should we follow RequireJS's lead and call it "shim"? My reasons for "legacy":

1. emphasizes the point nicely :)
2. avoids confusion with curl/shim modules

On the other hand, there are a few situations in which the config may be used with more than one loader.

Also, should we code this functionality into the js! plugin? Or should we keep the js! plugin light and force devs to opt-in to this feature via a preloads: ["curl/shim/legacy"] ?

[briancavalier]

I prefer "legacy" over "shim", but there might be some advantage in going with "shim" since people might recognize it from RequireJS.

The idea of a "preload shim to enable legacy config support" sounds pretty interesting. It seems like people would always want to use js! and legacy in conjunction, tho, so maybe smashing them together is best? I dunno ... seems like our pie-in-the-sky goal is for people to be able to stop using "js!" and go all-in-AMD.

[treasonx]

I never liked the name "shim" config. When it was the "use" plugin i thought the name was a little better but not great.

Legacy is nice but I dont feel like its the right term, its not so much legacy as it is just another way to load something into a JavaScript environment. Legacy seems like it'll eventually go away, and I dont think global namespaces are going away anytime soon.

Hmm so its sort of like an adaptor. Here are a couple.

• globalAdaptor
• webGlobal
• oldSchool :)

@briancavalier I would love to see everyone go "all-in-AMD", but that is never going to happen. Not in the JavaScript community unless it comes built into the browser or the language itself. Too many competing points of view on the subject.

[unscriptable]

@treasonx don't you think that when Harmony Modules arrive, global namespaces will immediately feel like legacy constructs?

I don't care what module system ppl end up using -- AMD, CJS, or Harmony -- as long as they're using modules. Non-modular code is legacy to me.

I've been trying to think of a word that describes the fact that these legacy scripts are non-modular and/or need to have their dependencies manually/externally configured. So far, I haven't found a good word. :)

[treasonx]

@unscriptable getting off topic, but you have a good point. I guess the practical me seem to think harmony modules won't make it to wide scale use until we can stop supporting some future version of IE which doesnt support modules. So in my mind somewhere around 2018 - 2022 :) Once we get to that point then global namespaces become legacy :)

[unscriptable]

@treasonx we plan to transpile from Harmony modules the minute the proposal seems stable. :) No need to wait.

[jaredcacurak]

"throwback" - A reversion to a former type or ancestral characteristic. or "atavism" - The return of a trait or recurrence of previous behavior after a period of absence. <-- Fancier

[briancavalier]

Another: "modularize" - perhaps more of a "pulling old stuff into the future" feel than a "curl looking backward" feel?

[unscriptable]

TIL a cool, new word, "avatism", that fits perfectly. :) But... ahh.... no way. :)

[unscriptable]

How about "depends"? You know, like the undergarmet.

[asilvas]

lol I love that name. In fact I wrote a loader library (very different from AMD) a few years back called "depends", before loaders were "cool".

https://code.google.com/p/jquery-depends-plugin/

Oh the memories. Had some interesting ideas around it that I've still yet to see in modern loaders.

[guybedford]

I'm working on a configuration tool - one of the goals would be to support many AMD formats. It seems the baseUrl, paths and packages configurations are all shared with RequireJS (but not map so I am avoiding this). But the one that I need critically to be able to ensure support would be the shim configuration.

Long story short, +1!

[guybedford]

Also, I notice the js! would need to be added, so there would be some incompatibility there. The fix for this would be to add a paths configuration for each shim item:

{
  paths: {
    'legacy/module': 'js!legacy/module'
  },
  shim: {
    'legacy/module': {
      deps: ['jquery'],
      exports: 'legacyModule'
    }
  }
}

But there is then some configuration redundancy there actually. Internally the above paths configuration could be added by curl, effectively making configurations identical. Just some ideas / food for thought, nothing critical though.

[guybedford]

Argh, actually the paths configs would probably cascade with the above config so it would need to be more internalized than that - it's a different require syntax anyway so this wouldn't be possible.

I still like the idea of sharing the shim spec though.

[unscriptable]

This has been implemented as a "module loader" -- an implicit plugin. The code is here in the dev branch: https://github.com/cujojs/curl/blob/dev/src/curl/loader/legacy.js

Take a peek! :)