Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rekapi doesn't lodash seamlessly with requirejs #39

Open
gilbox opened this issue Sep 8, 2015 · 4 comments
Open

Rekapi doesn't lodash seamlessly with requirejs #39

gilbox opened this issue Sep 8, 2015 · 4 comments

Comments

@gilbox
Copy link

gilbox commented Sep 8, 2015

Jeremy,

Thanks for posting about this. I am opening this issue at your suggestion.

To my knowledge, although rekapi can in theory work perfectly fine with lodash, it doesn't work out of the box when you are using requirejs. I think that in this file you are loading underscore for requirejs projects but you don't check to see if lodash is available. That's why whenever I setup rekapi with requirejs project using either browserify or webpack I always have to alias underscore to lodash otherwise rekapi doesn't work.

@jeremyckahn
Copy link
Owner

Hi @gilbox, thanks for reporting. Yeah, I guess I forgot about how Rekapi handles its dependencies. I'm not sure if there is a pre-established, accepted pattern for this sort of scenario, and it's not immediately clear to me how to feature detect for Lodash before falling back to Underscore. I'll play around with this and see if I can come up with a solution. Or, if you have any thoughts on how to resolve this, please let me know!

@jeremyckahn
Copy link
Owner

After trying a number of things and thinking about this all day, I am unable to come up with an "it just works" solution that doesn't create more problems than it solves. Every approach I've come up with will either break backwards compatibility (which I can't do unless I rev to 2.0.0), rely on non-public APIs of RequireJS (which are liable to become a bigger problem in the future), or attempt to load a Lodash that may not be there and then fall back to Underscore (which is inelegant, to say the least).

Since a configuration workaround for this issue exists, I am going to leave this open as something to be addressed for a 2.0.0 release.

Sorry I can't come up with anything better, but I am open to any suggestions on how to fix this in a way that doesn't cause problematic side effects!

@gilbox
Copy link
Author

gilbox commented Sep 9, 2015

+1 Yeah, I think that's fine. Afaik the only accepted pattern to handle this type of situation is to use aliasing. Some users will probably be a bit perturbed but ¯\_(ツ)_/¯

@jeremyckahn
Copy link
Owner

For what it's worth, I'd like to get rid of the Underscore/Lodash dependency altogether for 2.0.0. Not that many _ methods are being used, and the ones that are could be replaced by ES5 native methods or other helpers:

$: cat src/* | grep "_\.\w*" -o | sort | uniq

_.bind
_.chain
_.clone
_.contains
_.defaults
_.each
_.extend
_.findWhere
_.has
_.invoke
_.keys
_.last
_.map
_.pick
_.pluck
_.size
_.uniqueId
_.where
_.without

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants