# Problems importing loads-es from an Addon (possibly related to ember-auto-import)

**URL:** <https://discuss.emberjs.com/t/problems-importing-loads-es-from-an-addon-possibly-related-to-ember-auto-import/19308>\
**Category:** Questions\
**Created:** [November 23, 2021, 11:26am UTC](https://discuss.emberjs.com/t/problems-importing-loads-es-from-an-addon-possibly-related-to-ember-auto-import/19308 "2021-11-23T11:26:51Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![roomman](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/roomman/32/17451_2.png) [@roomman](https://discuss.emberjs.com/u/roomman)\
**Post date:** [November 23, 2021, 11:26am UTC](https://discuss.emberjs.com/t/problems-importing-loads-es-from-an-addon-possibly-related-to-ember-auto-import/19308/1 "2021-11-23T11:26:51Z")

</div>

Hi again! Back with another question about the best way to import / manage dependencies, after reading the docs and hitting a wall.

Ultimately, I am unclear about when (in an Embroider, Webpack, `ember-auto-import` world) I should add a package to:

- an App;
- an Addon’s dependencies; or
- an Addon’s Blueprint for installation in the parent App.

**Some background:**

I have an Addon running on Ember 3.28. It is `embroiderOptimized`, and has `ember-auto-import@2` in dependencies and `webpack@5` in devDependencies.

I have an Embroider enabled App with my Addon installed. It’s on the same version of Ember, and has `ember-auto-import@2` and `webpack@5` installed in devDependencies.

My project uses Lodash, via `lodash-es` so I can take advantage of some tree-shaking magic. 🤞🏻

Both Addon and App have their own, independent needs for Lodash.

Initially, I had the package installed in the Addon and the App dependencies, and just assumed that Embroider / Webpack would ensure only one copy ended up in the build. When I look at the Bundle Analyser I can see two copies of `lodash-es` in the same chunk. I also found that all the Lodash modules were included, not just the handful I have imported, via:

```auto
import { sortBy } from 'lodash-es';

```

My immediate priority was the duplicated packages. I moved Lodash into the Addon’s devDependencies and used a Blueprint to include the package in the App via `addPackagesToProject`. When I serve the app I get errors indicating that Lodash is missing:

```auto
"Could not find module `lodash-es` imported from `(require)`

```

The above should work, right? Either way, my Addon’s tests fail because they expect `lodash-es` to be in dependencies:

```auto
my-addon tried to import "lodash-es" in "my-addon/components/some-component.js" from addon code, but "lodash-es" is a devDependency. You may need to move it into dependencies.

```

I’m back to having duplicate copes of the package in the App build.

In this scenario (one package being shared by the App and Addon, for their own reasons) what is the correct way to manage the dependency?

Regarding tree-shaking the unused `loads-es` modules , what’s the correct way to import?

As always, thank you 🙏🏼

---

<div class="post-metadata">

**Author:** ![dknutsen](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/dknutsen/32/16471_2.png) [@dknutsen](https://discuss.emberjs.com/u/dknutsen)\
**Post date:** [November 23, 2021, 3:46pm UTC](https://discuss.emberjs.com/t/problems-importing-loads-es-from-an-addon-possibly-related-to-ember-auto-import/19308/2 "2021-11-23T15:46:06Z")

</div>

The addon will definitely need it in `dependencies`. The general rule of thumb is “if it’s needed by the addon code it must be in dependencies”, vs devDependencies are just needed to build the dummy app. This will all be much clearer with the v2 addon format (see below for further reading) because the dummy app will no longer be a part of an addon at all.

I think what you’ll want to do to deduplicate the lodash bundling is to have the addon add lodash as a `peerDependency` (IIRC this means it should be listed in both `dependencies` and `peerDependencies`). This signals that the addon expects lodash-es to be installed by the app that is using it, and it should use the app’s lodash version.

Anyway I think that’s the gist but ackages/bundling isn’t really my forté, someone like @ef4 could give you far more authoritative advice.

links: v2 addon format RFC: [https://emberjs.github.io/rfcs/0507-embroider-v2-package-format.html](https://emberjs.github.io/rfcs/0507-embroider-v2-package-format.html) article describing migrating to v2 addon format: [Migrating an Ember addon to the next-gen v2 format](https://www.kaliber5.de/en/blog/v2-addon_en)

---

<div class="post-metadata">

**Author:** ![roomman](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/roomman/32/17451_2.png) [@roomman](https://discuss.emberjs.com/u/roomman)\
**Post date:** [November 24, 2021, 9:07am UTC](https://discuss.emberjs.com/t/problems-importing-loads-es-from-an-addon-possibly-related-to-ember-auto-import/19308/3 "2021-11-24T09:07:24Z")

</div>

Thanks @dknutsen, I did read [Simon Ihmig’s post](https://www.kaliber5.de/en/blog/v2-addon_en) about migrating to the V2 format but that’s a project for 2022.

Thanks for the note about using `peerDependencies`, that’s good to know and something to try out. It still leaves me with a question about when I should use that approach, over using a blueprint to add it to the parent app directly.

---

<div class="post-metadata">

**Author:** ![dknutsen](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/dknutsen/32/16471_2.png) [@dknutsen](https://discuss.emberjs.com/u/dknutsen)\
**Post date:** [November 24, 2021, 4:22pm UTC](https://discuss.emberjs.com/t/problems-importing-loads-es-from-an-addon-possibly-related-to-ember-auto-import/19308/4 "2021-11-24T16:22:09Z")

</div>

I’d think you may want both, although the blueprint is more of an optional convenience thing. Using peerDependency in the addon is telling the package manager that the package is needed by the addon, but the addon should expect it to be present from the host app. The blueprint is just a convenient way of adding said package to the host app to help guarantee that it is there.

---

<div class="post-metadata">

**Author:** ![roomman](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/roomman/32/17451_2.png) [@roomman](https://discuss.emberjs.com/u/roomman)\
**Post date:** [November 24, 2021, 4:26pm UTC](https://discuss.emberjs.com/t/problems-importing-loads-es-from-an-addon-possibly-related-to-ember-auto-import/19308/5 "2021-11-24T16:26:48Z")

</div>

That makes sense, thanks. I’ll give that a shot 👍🏻

---

<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:** [November 26, 2021, 2:49pm UTC](https://discuss.emberjs.com/t/problems-importing-loads-es-from-an-addon-possibly-related-to-ember-auto-import/19308/6 "2021-11-26T14:49:58Z")

</div>

An addon is really two different packages: the addon itself and the dummy app. The dummy app has access to `devDependencies` and `dependencies`. The addon has access to `dependencies` and `peerDependencies`.

The choice between `dependencies` and `peerDependencies` comes down to whether you want to guarantee that the app and your addon will definitely get the same copy of the dependency. When it doesn’t matter if they’re different or duplicated, you can use `dependencies` and that guarantees that your addon will always bring its own copy, and that _might_ get optimized into the same copy the app is using but it might not. When you use `peerDependencies` you guarantee that they will share the same copy and the app must provide it.

When putting a library into `peerDependencies`, you will also typically put the same library into `devDependencies` in order to make the dummy app work. (The dummy app must provide the library to the addon, just as any other app would.)

---

<div class="post-metadata">

**Author:** ![roomman](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/roomman/32/17451_2.png) [@roomman](https://discuss.emberjs.com/u/roomman)\
**Post date:** [November 29, 2021, 8:59pm UTC](https://discuss.emberjs.com/t/problems-importing-loads-es-from-an-addon-possibly-related-to-ember-auto-import/19308/7 "2021-11-29T20:59:51Z")

</div>

Thanks @ef4, that’s very helpful. In terms of tree-shaking `lodash-es`, I’m following `ember-auto-import` docs but still finding all the modules in the final bundle. Any thoughts on what might be happening there?

I’m importing as follows, into a component’s backing class:

```auto
import { sortBy } from 'lodash-es';

```

**Update:**

Also having a related issue with importing `luxon`.

I am importing like this:

```auto
import { DateTime } from 'luxon';

```

But getting the following error when the component is rendered:

```auto
Error: Could not find module `luxon` imported from `(require)`

```

Importing like this works but Webpack puts all 272kb of `luxon` files in my bundle:

```auto
import { DateTime } from 'luxon/src/luxon';

```

S.O.S. - what am I not getting?

---

<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:** [December 1, 2021, 12:40am UTC](https://discuss.emberjs.com/t/problems-importing-loads-es-from-an-addon-possibly-related-to-ember-auto-import/19308/8 "2021-12-01T00:40:51Z")

</div>

There is an open issue [Support for tree shaking? · Issue #121 · ef4/ember-auto-import · GitHub](https://github.com/ef4/ember-auto-import/issues/121)