Created
November 14, 2011 18:50
-
-
Save jiggliemon/1364743 to your computer and use it in GitHub Desktop.
Library dependencies.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
// Defined in Framework | |
// Uses Mootools | |
define(['./localFile','Milk/core/Class'], function(local, Class) { | |
... | |
}); |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
// Defined in `Framework` | |
// Uses both Mootools and Polyfills | |
define(['./localFile','../../lib/Milk/core/Class', 'Polyfills/Array/Array.isArray'], function(local, Class) { | |
... | |
}); |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 | |
} | |
}) |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 resolveMooTools/Request/JSON
while internal packages of MooTools would requireRequest/JSON
. RequiringRequest/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.