Closed unscriptable closed 11 years ago
It's just this bit that it misses out, the define here right at the bottom of the file.
In other libraries cram seems to pick defines like this up..@
// some AMD build optimizers, like r.js, check for specific condition patterns like the following:
if (typeof define == 'function' && typeof define.amd == 'object' && define.amd) {
// Expose Lo-Dash to the global object even when an AMD loader is present in
// case Lo-Dash was injected by a third-party script and not intended to be
// loaded as a module. The global assignment can be reverted in the Lo-Dash
// module via its `noConflict()` method.
window._ = _;
// define as an anonymous module so, through path mapping, it can be
// referenced as the "underscore" module
define(function() {
return _;
});
}
Hey @gehan, feel free to try the latest cram dev when you get a chance. In my tests, lodash is working as of https://github.com/cujojs/cram/commit/7fa5d461cb9f2c87e5b6b59b9152d00688a724a2.
Will check it out now!
Yep works great with lodash now! Although it doesn't work with the minified source :(
While you have said this is a recipe for disaster, and so maybe not the worse thing, the minified source still has this code in it:
define(function(){return at}))
Therefore perhaps it should still be able to catch it?
i.e. its still a define call, albeit in minified code.
Code that is minified twice usually loses information in my experience. However, cram should be able to parse a minified file. I'll check out the minified lodash to see what's going on. Whatever I find will only make cram more robust.
Yes exactly. I have no idea if r.js can parse the lodash minified source, however if there is a clear define() call then I'm guessing it should be able to.
I think cram would also benefit from having more verbose output, it might be good for debugging problems. I know r.js prints out the dependency tree as it walks it, which is quite handy. No essential though obviously!
Also been talking with the other devs about the best way to do a tutorial on wirejs. The guys who have used it and understand it love it, but initially they hated it and didn't know wtf was going on. I think I have an idea - will post something soon! Although I think it might be a fine art between showing something trivial and something complicated!
I just tried lodash/dist/lodash.min.js and it built the bundle, and it ran fine. :/ Which lodash are you using?
oh really? i was using lodash.compat.min.s
lodash.compat.min.js
Ok. lodash.compat.min.js worked for me, too. :/ What's happening, exactly?
Oh weird, it's just ignoring the define()
call at the end and not setting the module name. It works with the non minified source. I'll try again..
argh. nm. you are right. it's not inserting the module id.
Yep it's just leaving the last line intact:
Z[U]=b,Z[G]=Z[H]=Z[J]=Z[K]=Z[V]=Z[Q]=Z[X]=Z[Y]=y;var nt={"boolean":b,"function":y,object:y,number:b,string:b,undefined:b},tt={"\":"\","'":"'","\n":"n","\r":"r","\t":"t","\u2028":"u2028","\u2029":"u2029"},rt=nt[typeof exports]&&exports,et=nt[typeo f module]&&module&&module.exports==rt&&module,ut=nt[typeof global]&&global;!ut||ut.global!==ut&&ut.window!==ut||(n=ut);var at=h();typeof define=="function"&&typeof define.amd=="object"&&define.amd?(n.=at, define(function(){return at})):rt&&!rt.nod eType?et?(et.exports=at).=at:rt.=at:n.=at
i.e. this call:
define(function(){return at})
Regex fun!!!
The scan/compile step works. It's the link step that's failing.
Sorry. The whole process works for lodash.min.js, but the compile/scan step fails for lodahs.compat.min.js.
Yeah I had a look a the .meta output and the modules list is empty for lodash.compat.min, which is weird as lodash.min isn't much different
Had a quick try and seems to work with lodash.compat.min! I see you've bumped the version so assume there is a release imminent..!
Yah, seems like we should release asap.
Released! Version is 0.7.5 because of a git tag snafu. :/
Wooo!
cram's parser needs to be more robust. It get's confused by several of the crazy things lodash does internally.