February 6, 2019
Lenient libraries, strict applications
The EmberMap Podcast
Sam and Ryan discuss the current state of frontend dependency management, and the areas where it leaves much to be desired. They talk about best practices for how applications and libraries should specify their dependencies, and also what happens when those practices aren't followed.
How to listen
Watch above, or find us on your favorite channel:
- 04:01: Welcome to Node Dependency Hell.
- 14:00: How should the way we declare dependencies change if an addon is an implementation detail of another addon?
- 21:45: Can Ember CLI address these problems a layer above Yarn/npm?
- 26:21: Someone's app broke when they installed their dependencies due to a Mirage dependency changing. How can we reliably solve this for users?
- 35:05: Even if the tooling were better, there's a cultural problem where JS library authors don't consider the dependencies they bring in.
- 39:04: Lessons learned:
- apps should specify strict dependencies, libraries (including addons) should specify lenient dependencies
- apps should use lockfiles
- ember-dependency-lint & yarn resolutions are a good top-level escape hatch
- addons should use the
dependencies key &
ember-auto-import for most of their dependencies
- 41:12: 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.
- 48:33: Would you build Ember CLI Tailwind the same if you were building it from scratch today?
- 54:55: Call for input. What are any best practices that we've missed? What did we get wrong?
- 59:20: Mirage blog using GitHub issues teaser