: Welcome to Node Dependency Hell.

: How should the way we declare dependencies change if an addon is an implementation detail of another addon?

: Can Ember CLI address these problems a layer above Yarn/npm?

: Is JavaScript's fractured module ecosystem (CommonJS in node vs. ES6 modules in the frontend) contributing to the problem?

: Someone's app broke when they installed their dependencies due to a Mirage dependency changing. How can we reliably solve this for users?

: Even if the tooling were better, there's a cultural problem where JS library authors don't consider the dependencies they bring in.

: Lessons learned:

: Ember Auto Import attempts some deduplication of dependencies. If you're writing an addon that has a dependency the host app cares a lot about, you can use addPackagesToProject to put the burden on host app.

: Would you build Ember CLI Tailwind the same if you were building it from scratch today?

: Call for input. What are any best practices that we've missed? What did we get wrong?

: Mirage blog using GitHub issues teaser