Search

Home > Frontend First > Lenient libraries, strict applications
Podcast: Frontend First
Episode:

Lenient libraries, strict applications
Category: Technology
Duration: 01:02:08
Publish Date: 2019-02-06 11:00:00
Description:

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 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

Links:
Total Play: 0