# Lodash is bigger than you think

**URL:** <https://discuss.emberjs.com/t/lodash-is-bigger-than-you-think/16364>\
**Category:** Uncategorized\
**Created:** [March 26, 2019, 3:59pm UTC](https://discuss.emberjs.com/t/lodash-is-bigger-than-you-think/16364 "2019-03-26T15:59:07Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![ef4](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/ef4/32/13470_2.png) [@ef4](https://discuss.emberjs.com/u/ef4)\
**Post date:** [March 26, 2019, 3:59pm UTC](https://discuss.emberjs.com/t/lodash-is-bigger-than-you-think/16364/1 "2019-03-26T15:59:07Z")

</div>

This PR is a fun little example of how a tiny change in usage patterns can cause a huge impact in how much code you’re pulling into your app:

> <https://github.com/miragejs/ember-cli-mirage/pull/1561>
>
> This PR cuts more than half a megabyte from any app that uses mirage.
> 
> The pro…blem is that:
> 
> \`\`\`js
> import \_ from 'lodash';
> let item = \_(value);
> \`\`\`
> 
> needs to put methods on \`item\` for every possible thing lodash supports. Most of which aren't needed.
> 
> This isn't one of the cases where a more aggressive module bundler could try to optimize them out. This style really just can't be statically optimized. It's a pity, because the chaining style is easier to read IMO.

---

<div class="post-metadata">

**Author:** ![efx](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/efx/32/17920_2.png) [@efx](https://discuss.emberjs.com/u/efx)\
**Post date:** [March 27, 2019, 1:34pm UTC](https://discuss.emberjs.com/t/lodash-is-bigger-than-you-think/16364/2 "2019-03-27T13:34:15Z")

</div>

@ef4 Thanks for posting this! I will definitely apply this pattern to my use of lodash.

How does this differ from using named imports, e.g. `import { isFunction } from 'lodash'`? Curious if that would reap the same benefit. Found a [codemod](https://github.com/cpojer/js-codemod/blob/master/transforms/underscore-to-lodash-native.js) that partly does that transform.

For context, if you are using [ember-auto-import](https://github.com/ef4/ember-auto-import) for lodash or other dependencies, when analyzing the output with [ember-cli-bundle-analyzer](https://github.com/kaliber5/ember-cli-bundle-analyzer), you may not see those dependencies included in the analysis. This is a known issue:

> <https://github.com/stefanpenner/broccoli-concat-analyser/issues/34>
>
> It appears that broccoli-concat-analyser doesn't include packages which have bee…n imported using ember-auto-import. I'm unsure whether the issue is in this addon or ember-auto-import but thought I'd open it here first.
> 
> To reproduce the issue I've made a sample repo where I've done the following:
> 1. Installed ember-auto-import
> 2. Installed lodash
> 3. Imported lodash into app/app.js
> 
> Running \`ember asset-sizes\` we get the following size vendor.js
> \`\`\`
> File sizes:
> - dist/assets/vendor.js: 3.2 MB (683.25 KB gzipped)
> \`\`\`
> 
> But broccoli-concat-analyser outputs the following size for vendor.js
> \`\`\`
> - dist/assets/vendor.js: 2.65 MB (218.44 KB gzipped)
> \`\`\`
> !\[image\](https://user-images.githubusercontent.com/685034/44774121-304c7400-ab6a-11e8-8a42-82807047a88d.png)
> 
> There looks to be a large discrepancy there. Looking at the generated stats it appears the auto-imported \`lodash\` has been excluded.
> 
> !\[image\](https://user-images.githubusercontent.com/685034/44775761-51af5f00-ab6e-11e8-81ec-d9432fa5c314.png)
> 
> The reproduction repo is \[here\](https://github.com/patocallaghan/auto-import-analyser) and I've committed the \[generated broccoli-concat-analyser stats\](https://github.com/patocallaghan/auto-import-analyser/tree/master/concat-stats-for)

---

<div class="post-metadata">

**Author:** ![ef4](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/ef4/32/13470_2.png) [@ef4](https://discuss.emberjs.com/u/ef4)\
**Post date:** [March 27, 2019, 3:33pm UTC](https://discuss.emberjs.com/t/lodash-is-bigger-than-you-think/16364/3 "2019-03-27T15:33:17Z")

</div>

> [@efx](#):
>
> How does this differ from using named imports

If you’re using plain `lodash`, the main entrypoint file is not authored as an ES module, so you definitely will not be able to strip out the unused parts.

But if you switch to `lodash-es`, you get an entrypoint that is an ES module. By itself, that’s still not enough to drop unused exports, but Webpack 4 (as used inside ember-auto-import) looks for a webpack-specific `sideEffects: false` setting in package.json that allows libraries to declare that it’s safe to strip unused imports. `lodash-es` has that setting, so it _should_ work the way you’d hope.

> [@efx](#):
>
> if you are using [ember-auto-import](https://github.com/ef4/ember-auto-import) for lodash or other dependencies, when analyzing the output with [ember-cli-bundle-analyzer](https://github.com/kaliber5/ember-cli-bundle-analyzer), you may not see those dependencies included in the analysis.

Oh yes, I have a better workaround I can suggest for this now. It doesn’t give you one complete picture, but it gives you a separate report for the things that auto-imported:

```js
// 1. yarn add --dev webpack-bundle-analyzer
// 2. Configure auto-import like this:
autoImport: {
  webpack: {
    plugins: [
      new (require("webpack-bundle-analyzer")).BundleAnalyzerPlugin(),
    ],
  },
},
// 3. ember server

```

---

<div class="post-metadata">

**Author:** ![efx](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/efx/32/17920_2.png) [@efx](https://discuss.emberjs.com/u/efx)\
**Post date:** [April 4, 2019, 2:22pm UTC](https://discuss.emberjs.com/t/lodash-is-bigger-than-you-think/16364/4 "2019-04-04T14:22:39Z")

</div>

I started a codemod to migrate usage for anyone that has multiple references and doesn’t want to manually migrate them: [https://github.com/efx/ember-lodash-single-import/](https://github.com/efx/ember-lodash-single-import/)

Handful of things still left but this rewrites most simple uses. If I get some time in the next month I hope to polish this.