We should quite possibly just use lodash-node

[HenrikJoreteg]

suggested by @legastero

https://www.npmjs.org/package/lodash-node

[HenrikJoreteg]

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.

[jdalton]

It should work fine with browserify.
I had to tweak my system's ulimit but that was easy enough.

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 lodash package will have the lodash-node/modern build included so you'll be able to do require('lodash/array/compact') right from the lodash package and the other builds will be have to their own packages, require('lodash-underscore/array/compact'). We'll update lodash-node, lodash-amd, & lodash-es6 to 3.0 as well.

[latentflip]

@jdalton with 3.0, if a submodule has require("lodash/array/compact") and the parent application just require("lodash"), will the lodash/array/compact references dedupe since they'll now point to the same file?

I tried testing it, but it sounds like 3.0.0-pre isn't there yet as require('lodash/array/compact') wasn't working installing from lodash/lodash on github?

[jdalton]

with 3.0, if a submodule has require("lodash/array/compact") and the parent application just require("lodash"), will the lodash/array/compact references dedupe since they'll now point to the same file?

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 require('lodash') will still load a monolithic build that is not composed of individual module references. This is to support _.runInContext, lazy evaluation, and ease up on load time. The individual modules are included to allow devs to go method by method if they want. This is based on the assumption that if you're using the individual modules you'll probably not be using the monolithic/full require('lodash') invocation.

I tried testing it, but it sounds like 3.0.0-pre isn't there yet as require('lodash/array/compact') wasn't working installing from lodash/lodash on github?

I'll be making the repo structure changes this week.

[phated]

I believe @jdalton is correct that npm dedupe would reduce size on disk, but node and browserify would load them as 2 separate modules because they are different files.

[lukekarrys]

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...
browserify app.js > app.bundle.js

In app.bundle.js I only get one reference to lodash's extend, bind and keys functions.

@jdalton Are you saying that with v3, lodash will do this by default? And if all references to lodash-node were replaced with lodash in the example above, the result would be the same?

@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 lodash-node?

[jdalton]

jdalton Are you saying that with v3, lodash will do this by default? And if all references to lodash-node were replaced with lodash in the example above, the result would be the same?

The paths would be different but ya the same general thing would apply as long as you aren't doing require('lodash') and stick with require('lodash/object/assign'). We'll still update the lodash-node package and friends for 3.0 too.

You all could use lodash-node now and when v3 is release transition to lodash if that's something you're interested in.

[lukekarrys]

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 lodash-node for modules doesn't have as a big of an effect on bundle size as I thought it would.

[jdalton]

So awesome!! I noticed that initially the lodash-node is the smallest but when both contain lodash-node it's considerably larger. However, others where they share the same package more closely resemble the base size of the package. For example I would expect lodash-node--lodash-node to be around 2.35 kB min instead of 15.72 kB min.

Can you explain that a bit more.

[lukekarrys]

@jdalton I noticed that too, but I'm not 100% sure why. Investigating that a bit more.

[lukekarrys]

@jdalton The module that uses lodash-node is the smallest because it directly requires assign, bind and keys, so those are the only methods that end up in the bundle.

But to simulate what would happen when an application uses lodash-node I made it require the whole thing, so every method ends up in the browserified bundle. If you check out that bundle though, you'll see that browserify does dedupe properly since only one reference to assign ends up in the bundle.

[jdalton]

Ah thanks for digging into that. If they are using lodash-node I don't think kitchen-sinking lodash-node would be common (as the point is to pick the bits you need & using 100% of the methods is rare). It would be nice if the dummy app used a subset (as most would) and then compare the numbers again, understanding that as more methods are used, and the less intersection between them, the larger the size would become.

I also get that you may be trying to see worse case scenario or simulate what the result would be if lodash referenced all modules but it'd be great to see the intersecting case for lodash-node, where I think it will shine.

[lukekarrys]

Not to get too much further down a rabbit hole with intersecting scenarios, I think using lodash-node for all the ampersand modules is a good choice.

If all modules used lodash-node then any combination of browserified modules wouldn't have any utility code duplication, and the individual modules would have the smallest bundle size. It also doesn't hurt the app size too much if a developer does require('lodash') or require('underscore') in their app. We could also recommend using lodash-node individual pieces (if they are into byte counting), in which case no code would end up duplicated.