Lenient libraries, strict applications
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.
Topics include:
- 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?
- 23:25: Is JavaScript's fractured module ecosystem (CommonJS in node vs. ES6 modules in the frontend) contributing to the problem?
- 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
dependencieskey &ember-auto-importfor 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
addPackagesToProjectto 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