41 min listen
Lenient libraries, strict applications
FromFrontend First
ratings:
Length:
62 minutes
Released:
Feb 6, 2019
Format:
Podcast episode
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:
Ember Auto Import
Discourse topic on conflicting dependencies
Dependency Lint
Ember CLI Addon Docs
Ember CLI Tailwind
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:
Ember Auto Import
Discourse topic on conflicting dependencies
Dependency Lint
Ember CLI Addon Docs
Ember CLI Tailwind
Released:
Feb 6, 2019
Format:
Podcast episode
Titles in the series (100)
Photo Uploads, Server Errors in Ember Data, NPM Dependencies and Ember CLI Addon Docs: Sam and Ryan talk about uploading images to S3, a new Storefront API for dealing with server errors in Ember Data, how to be a good community citizen when it comes to publishing consumable libraries given that our package managers now use lockfiles, and some ongoing work on the Ember CLI Addon Docs addon. by Frontend First