liveBook · Manning

Dependency hell

As explained in Web Components in Action

Dependency hell is a software-maintenance condition in which numerous interdependent resources create difficult tracking, ordering, and version-management problems.

Dependency hell appears when a component grows beyond one file and consumers must track its scripts, styles, markup, and nested components. A page with one component containing eight more, each with several children, turns dependency ordering and inclusion into a maintenance task. section 5.1

The practical warning signs are:

  • Separating markup, controller logic, and styles across files without hiding those requirements from consumers. section 5.1
  • Managing custom Web Components nested inside other custom Web Components. section 5.1

Reducing the consumer's dependency list

A photo carousel initially needs photocarousel.js and photocarousel.css. Moving the CSS into the component's innerHTML lets the consumer load only photocarousel.js, while the component manages its own styling.

How Web Components in Action covers it

How deep it goes
Defines the maintenance problem and demonstrates dependency reduction, but stops short of detailed module-loading or build-system internals.
Examples
Uses a photo carousel, a multi-component index.html, embedded component CSS, and a single build script.
What it assumes
Assumes familiarity with HTML pages, script tags, stylesheets, and custom Web Components.
What you can do after
Apply it by hiding component styles and dependencies behind a single script consumers load directly.
How it connects
Connects dependency hell to Web Components, modules, HTML, CSS, JavaScript, and nested component composition.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Web Components in Action. The section links point to the parts of the book it draws on.