-
-
Save jiggliemon/1364743 to your computer and use it in GitHub Desktop.
| // Defined in Framework | |
| // Uses Mootools | |
| define(['./localFile','Milk/core/Class'], function(local, Class) { | |
| ... | |
| }); |
| // Defined in `Framework` | |
| // Uses both Mootools and Polyfills | |
| define(['./localFile','../../lib/Milk/core/Class', 'Polyfills/Array/Array.isArray'], function(local, Class) { | |
| ... | |
| }); |
| require({ | |
| packages: [ | |
| { | |
| name: 'Poly' | |
| ,location: '/js/lib/Polyfills/Source' | |
| } | |
| { | |
| name: 'Mootools' | |
| ,location: '/js/lib/Milk/Source' | |
| } | |
| ,{ | |
| name: 'Framework' | |
| // this framework names Mootools as Milk | |
| // and Polyfills as Polyfills | |
| ,location: '/js/lib/Other/Framework' | |
| } | |
| ,{ | |
| name: 'App' | |
| ,location: '/js/app/' | |
| } | |
| ] | |
| ,callback: function () { | |
| //.. make shit happen | |
| } | |
| }) |
The current repositories of MooTools (Milk), have quite generic names, Base, DOM, Fx, Request, Color, JSON...
Therefor I could see some (hypothetical) collisions.
Because these projects, although they are separate packages, should work well together (when they're finished one day). It would be convenient to just download the whole package, tell the loader 'MooTools' stuff is there, and don't bother with the individual packages. The same would apply to dojo packages: dojo/dojox/dijit.
Extending on that idea passing something like 'MooTools' => '../Milk' to the loader config, would know how to resolve MooTools/Request/JSON while internal packages of MooTools would require Request/JSON. Requiring Request/JSON outside the MooTools group of packages, would try to load another file.
What if two dependent packages have a dependency of different versions of a third packages, but both use Request as absolute mapping?
I don't think something like I just described exists in either the Curl, Requirejs or dojo loaders.. right @unscriptable, @jrburke?
This may sound nice, but on the other hand it adds extra complexity, and how realistic is this (dependency hell?), is it a difficult problem, how many different packages will you have in a (big) application and how hard is it to maintain.
It's a complex problem for sure. Devs want to configure their apps and/or frameworks in all sorts of crazy ways. To my knowledge, @cadorn is the only one who's come up with a way to handle all (sane) use cases (via Package/Mappings/C) in BravoJs/PINF, including the ones you've described, @arian. https://github.com/cadorn/pinf
If one package is calling a dependent package by the name "Milk" and a second package is calling it "MooTools" then the loader (or builder) won't know that they're the same package. I've been considering a new feature for curl.js that would allow you to easily create package aliases.
Also, I've been thinking about implementing CommonJS Package/Mappings/C, which should handle this case. BravoJs/PINF uses Mappings/C already.