Best practices for including 3rd-party libraries in an addon

1

I’m catching up on Mirage issues, and am working on this issue requesting that we bump Faker.js to 4.0.

Mirage includes faker.js as a dependency. The idea was to provide it for a nice out-of-the-box testing experience.

Since faker is used directly by Mirage users, they have at times requested (with good reason) more control over the version. That is, faker is not really an implementation detail of Mirage, it’s more of a first-class thing.

Because of this, should I use this.addAddonToProject in a blueprint and move it to devDependencies? Does that mean I need to create a shim (similar to ember-cli-moment-shim)?

In general, what’s the best practice for addons wanting to make other packages available to their users?

1 Like
2

faker is really a peerDependency of mirage, since both the app and mirage want to have direct access to it. But NPM is bad at installing peer deps, so we’re stuck with blueprints that manipulate the app’s deps.

I hope people stop making shims, in favor of ember-auto-import (and eventually first-class support in ember-cli for the same thing).

This example has made me realize I need to make a tiny change in ember-auto-import. It only allows a package to import things that appear in that package’s dependencies (for addons) or devDependencies (for apps or addons). But it should also allow things that appear in peerDependencies.

Once I do that, you could add these to Mirage:

"dependencies": {
  "ember-auto-import": "..."
},
"peerDependencies": {
  "faker": "..."
}

And use a blueprint to put faker into the app’s devDependencies.

At that point, auto-import is only enabled inside mirage. As long as mirage imports faker, it will end up in the app. And our runtime AMD loader being what it is, this will have the side effect of allowing the app to also import from faker, without accidentally allowing the app to auto-import anything else.

Later if the app also chooses to use ember-auto-import, everything still deduplicates correctly.

4 Likes
3

Awesome. Seems like the right path forward!

4

BTW, I already added the peerDep support to ember-auto-import.

2 Likes
5

@ef4 circling back to this now – would you still recommend this approach?

What happens if Mirage has faker as a peerDependency, but the host app forgets to run the blueprint (say during an upgrade)? Would npm/yarn be able to call the problem out at build-time?

Are there any addons using peerDependencies at all, or in the way you recommend?

1 Like