mimosa
mimosa copied to clipboard
dbashford
Mimosa growls about valid require maps
If i've asked about this before, and you've given me an answer, I apologize in advance for repeating myself. I have some vague memory of discussing it with someone but I cannot find any references to it in the issues. I have the following valid RequireJS config section, but Mimosa complains.
map:
"*":
backbone: "backbone_noconflict"
jquery: "jquery_noconflict"
lodash: "lodash_noconflict"
underscore: "lodash_noconflict"
backbone_noconflict:
backbone: "backbone"
jquery_noconflict:
jquery: "jquery"
lodash_noconflict:
lodash: "lodash"
Here are the warnings:
22:39:47 - Mapping inside file [[ /run/media/neverfox/Data/Linux/Repos/my-project/public/javascripts/app/main.js ]], refers to module that cannot be found [[ backbone_noconflict ]].
22:39:47 - Mapping inside file [[ /run/media/neverfox/Data/Linux/Repos/my-project/public/javascripts/app/main.js ]], refers to module that cannot be found [[ jquery_noconflict ]].
22:39:47 - Mapping inside file [[ /run/media/neverfox/Data/Linux/Repos/my-project/public/javascripts/app/main.js ]], refers to module that cannot be found [[ lodash_noconflict ]].
Is it possible to get rid of these growls? These are currently the only warnings that get thrown when I start up mimosa watch and it would be nice to get rid of them since they're not really a problem.
FYI, this is coming from Mimosa 1.1.4 since I've frozen it in for a project that cannot withstand dependency changes. If this is already cool in newer Mimosa versions, that's great.
That looks to still be a problem.
Can you walk me through the reason for all that? Not because I'm questioning it, but because I've not done a ton with maps and I want to be clear what's going on.
Narrowing in on the below...
"*":
backbone: "backbone_noconflict"
backbone_noconflict:
backbone: "backbone"
Anytime backbone is encountered, give it backbone_noconflict. Does backbone_noconflict exist on the file system, or is it just there as a proxy to the more specific map?
Anytime backbone_noconflict is encountered, for its backbone dependency, give it backbone. I get that. Though, that seems like it wouldn't actually change anything. Why tell it it needs backbone when its already going to just get backbone?
That's all twisty, I need to make sure I understand the point and the bahavior before I try to fix it.
The basic idea is that I have two files in my vendor folder for backbone (or jQuery or whatever): the regular library and a backbone_noconflict.coffee module that I write myself. It just contains the following:
define ["backbone"], (Backbone) ->
Backbone.noConflict()
The map tells require that when any module calls for backbone, give it the backbone_noconflict module (which returns Backbone with the provided noConflict method applied), unless the requesting module is the backbone_noconflict module itself, in which case, give it the real backbone module. This is a trick to keep everything out of the global namespace.
But it seems that what I'm doing is really just leveraging normal map behavior. If something appears at the top level of the map specification, it should be recognized as valid for use as a string in some other part of the map, but it's not.
@neverfox you should use shim and paths with depts/exports correctly, map is only for plugin hooks.
Basically you could create one backbone inside paths as BB, add the correct path, add your small script as backbone, set the noconflict mode and then export Backbone.
That's the way to go.
I remember many moons ago wondering if you could map to maps and deciding it seemed an odd use case so I just let it be.
I'll play with making this work.
Why would anyone do this? :-1: The proper way is using dependency management and export-syntax.
No need to be rude about it. =)
maps to maps are valid regardless of the use case.
Sorry if it seems "rude", but I'm sure he is using this way because he doesn't know which one is the proper way. We should encourage users to do it the normal way, so they wont run into troubles in the future =)
Your assumption is wrong. I'm quite well-aware and well-versed in shims...and I despise them. I seek to do whatever it takes to avoid their use in my projects. They're nothing but a crude band-aid in my opinion, and to the extent they're the "proper" or "normal" way, then call me a rebel, but what troubles am I going to run into exactly, using a RequireJS feature the way it was designed? If that leads to trouble, then you should alert the developers of RequireJS to the problem.
Maps are not just for plugins (whatever that means, since every AMD module is a "plugin"). Their expressly documented purpose is for cases where one "may have two sets of modules that need to use two different versions of 'foo', but they still need to cooperate with each other." In other words, when you want to have a module name string refer to different modules in different contexts, you use maps. And that's what I'm doing. I want "backbone" or "jquery" to mean different things in different contexts. Yes, I could do the whole "bb" thing in paths and get the same result but that's not what I want to do. You can consider that pointless or overly OCD all you want, but there's no basis for claiming that it's improper or incorrect. It's just a practice I do consistently because there are more complex use cases where that practice pays off.
For example, I might have a module that does much more than noConflict and I need both the original and the patched version somewhere in my code. I can rewire everything as needed just by changing my map and all the code I had originally written to use the single module name will work as I want it to. If I just created a bunch of new entries in path (which I have to do in either case), then I'd have to go change it everywhere it's necessary in the source code. With maps, I get a sort of "switchboard" I can use to reconfigure on the fly.
If dbashford thinks it's too much of an edge case for Mimosa, then I can respect that, but like he said, maps to maps are valid in general.
I wanna apologize if I seemed rude, based on your comments that was the case. All I'm trying to find out is why you wanna do it this way? Why are they crude band-aid?
No worries. Check out the rest of my reply. I think I added stuff before seeing you had replied. Even the AMD docs admit that shims are "a stop-gap measure for non-modular code." They work fine but I simply prefer, if I'm using AMD, to get everything on the same page. I'll add my own UMD wrapper or submit pull requests to libraries to get AMD-support added.
My POV as the maintainer of Mimosa is that if require.js lets you do it, mimosa ought not give you an error for it.
And in this case that is all that matters. I too wouldn't manage it that way, but I also don't find any real issue with it.
I may take a week or so to get to this. I have a bunch of other things queued up that I want to hammer out in the very short-term.
@neverfox I poked at this for a real brief period this weekend. Do you have paths defined for backbone_noconflict and backbone? Guessing you do. It seems to work fine if backbone_noconflict actually sits in the root. I was playing with it that way and confused why I wasn't seeing it break like I did last week when I was initially trying it out.
It would be great if you could set up a really dead simple sample project and toss it up on GH. Hopefully that's just a few minutes of your time. I want to make sure I get this right so I want to be sure I'm working with your exact scenario. No need for 3 different maps to maps. Just setting up jquery would work as far as I'm concerned.
I'd love to hack on this while my mind is still in the mimosa-require code from previous updates. If you get a chance, could you sling a quick repo together?