-
Notifications
You must be signed in to change notification settings - Fork 12
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
We should quite possibly just use lodash-node #2
Comments
Not sure if there's any issues with using it in the browser? The name makes me wonder if it's meant to be node specific, or just that it plays nice with browserify. |
It should work fine with browserify. The lodash-node bundle includes builds so you can choose to support compat, modern, or the underscore build. When we bump our packages to 3.0 the primary |
@jdalton with 3.0, if a submodule has I tried testing it, but it sounds like 3.0.0-pre isn't there yet as |
Yes, dedupe would work (move the package higher up the folder structure) based on the package+version. However, Browserify would bundle it as 2 different modules because using
I'll be making the repo structure changes this week. |
I believe @jdalton is correct that |
I just tested something like this: myModule.js var extend = require("lodash-node/modern/objects/assign");
var bind = require("lodash-node/modern/functions/bind");
var keys = require("lodash-node/modern/objects/keys");
// A made up module that uses extend, bind and keys
module.exports = function () { /* ... */ }; app.js var _ = require('lodash-node');
var myModule = require('./myModule.js');
// Uses _ and myModule then... In @jdalton Are you saying that with v3, lodash will do this by default? And if all references to @HenrikJoreteg @latentflip If so, that sounds like a pretty good solution to me once v3 is released. If not, is it good enough to tell devs to use |
The paths would be different but ya the same general thing would apply as long as you aren't doing You all could use |
So I got very curious about what happens when modules and applications use different util libraries and the effect on the overall bundle size after browserify-ing. I was writing up another comment with the output of some code, and well... https://github.com/lukekarrys/util-lib-compare#output Basically, what I found is that using |
So awesome!! I noticed that initially the Can you explain that a bit more. |
@jdalton I noticed that too, but I'm not 100% sure why. Investigating that a bit more. |
@jdalton The module that uses But to simulate what would happen when an application uses |
Ah thanks for digging into that. If they are using I also get that you may be trying to see worse case scenario or simulate what the result would be if |
Not to get too much further down a rabbit hole with intersecting scenarios, I think using If all modules used |
Ok, so I watched Henrik's Backbone conf video to see the issues raised against lodash and I wish they were raised beforehand so we could have mentioned that they're being addressed and we could have worked with Ampersand. It's a bummer to have put so much potentially unnecessary effort into a fork. I've noticed that while many of the |
Perhaps so. I think goals were somewhat different and would have required changing your publishing strategy and versioning them independently as well as extending your scope to also include DOM-related functionality. There's no way Underscore would (or should have) gone along with that. Arguably we should have checked with you folks working on lodash on this but it seemed unlikely you'd want to make those rather drastic changes and I didn't see the harm in going this route.
how so? Also, I wanted something like this to exist for the sake of us having a clear place and mechanism for adding new things to it as we needed them. It's obviously a bit of an idealistic dream, but the goal is for this to not be a huge on-going effort for us, but rather a place for us to categorize, test and document "done" utility code. I guess the thing is, does it matter? I don't see the harm in both existing. |
I guess also, if you obviate the need for amp, then... great! :) |
We've extended our scope in the past with the inclusion of string methods and lazy evaluation. I also don't think that would have prevented building on top of existing projects and supplementing for things like
You totally should have 😸. We're pretty open to working with projects. That's why we're one of the most customizable and accommodating projects out there offering custom-builds, grunt plugins, individual modules and bundles for AMD, CommonJS, Node, ES6, & npm.
For example your
I had no idea when I started that 3 years later things wouldn't be "done". It goes on and on.
It would have been nice to avoid further splintering utils for something as trivial as modules/shallow-deps. Esp. since you'll likely continue to run into issues like those I mentioned earlier, issues others have tackled and are committed to tackling in the future.
I wish you would have reached out :( |
As a (not-so casual) observer, it still seems that
Many of the other points made here are already handled by @jdalton has already filed at least a dozen issues in this repo, which poke numerous holes in the '1.0 and done' theory. I just don't buy into the "solved problem" argument - no software is ever perfect. What would be required to get lodash to distribute as separate tiny modules? It sure sounds like the lodash crew is more than willing to work with ampersand. Personally, I think we should push further down this path instead of introducing the fragmentation of &yet another competing library into the utils ecosystem. Breaking the utils into separate modules actually seems like a logical step from |
While I may not have chosen the same route, I've come to understand why the Ampersand crew went down this path. I think this post explains it pretty well. Yes, it's very similar to post.md mentioned previously, but somehow makes the points a little clearer. When you get right down to it, not "wanting to track lodash" was enough reason for this library to exist. Only time will tell how well Optimizing for “done” works out, but I give the Ampersand team some credit in making the bold choice. Hopefully many (if not most) of these modules will never require a major bump. I'm sure there will be changes under the hood, but the API should stay the same. And...at this point, the ~4 month investment in |
With lodash v3 out now I wanted to give an update on some of the lodash issues mentioned in the Modularizing Underscore.js post. In v3 the dep graphs for modularized packages have been significantly reduced.
Minor nit, the post links to lodash.bind which incorrectly suggests its dep graph is still large. What's interesting is now the post could be tweaked to reference Amp itself:
Take the similar package lodash.compact:
Amp is largely ported from Underscore which is not designed to be modular. So they're getting unnecessary dependencies and less than stellar performance too.
lodash v3 now has modules available in its primary package: var clone = require('lodash/lang/clone') Module paths are easy to remember because they map directly to their documented categories.
Devs can use
In lodash v3 modularized packages are updated independently of the stable version (from 3.0 up to around the current stable version). Some are 3.0.0, others 3.0.1, and others 3.1.0. Bumps are handled automatically by lodash-cli which makes managing 150+ modules a breeze and helps avoid oversights.
In v3 several smaller functions like
It's complicated. Amp appears to have v2.0 work lined-up and has to walk a precarious path to keep from bumping while following semver. With Amp porting Underscore much of the history of fixes, implementation rationale, & direction is lost. Even in this short time since Amp's release, Underscore has optimized and fixed bugs that are missing in Amp. Keeping up with fixes, features, & optimizations is time consuming so the gap will likely widen. |
suggested by @legastero
https://www.npmjs.org/package/lodash-node
The text was updated successfully, but these errors were encountered: