How packaging makes it dead simple to share UI components

Packaging provides a uniform way to enclose unwieldy objects. A chocolate bar’s thin plastic wrapper encloses the delightful but messy treat. It provides a convenient user-friendly method of distribution.

In the component realm, packaging plays a similar role. Diverse UI components become easier to share when they have uniform wrapping. The benefits are twofold: individual components are effortless to consume in your apps (e.g., install datepicker) and the component library is more durable at scale. Let’s see why.

Package management

Component libraries can contain hundreds of UI components spread across different codebases. Since the goal of a library is to manage and share components it’s obvious to start with a package manager.

Package managers automate the process of installing, upgrading, configuring, and removing code in an app in a consistent manner.

As the de facto package manager for JavaScript, NPM is a natural home for components. It takes care of distribution, versioning, dependencies so you don’t have to. The first step toward reusability is to distribute UI components as NPM packages. So why aren’t people doing this already?

Packaging makes it simple to install, improve, and jettison UI components.

NPM is not so easy…

Packaging a component for NPM involves moving a component from an app to a new repo, creating a new NPM package, and setting up a build process. Is it really worth the work just to get the same menu in two apps? Isn’t it easier to copy a directory or use a git submodule?

It’s simpler to duplicate directories and use submodules, but there are distinct downsides:

• Copy pasting directories makes it super hard to ferry improvements to a component from app to app. Components quickly become out of date in the absence of a clear source of truth.
• Submodules are hard to version and don’t track dependencies. If you have a reusable component like a CreditCardForm that relies on subcomponents CardInput and DatePicker, there’s no easy way to tell if those subcomponents have been updated.

These downsides rule out submodules and copying directories as viable strategies for long term component reuse and library building.

What to do about component packaging

Despite NPM being the closest solution for reusability, its workflow is too onerous. The out of box features are too broad to suit the specific use case of UI component libraries. However, great open source solutions can make packaging UI components on NPM a breeze.

• Manage your UI components in a single app repo : Lerna optimizes the package management workflow for mono-repos that contain many packages. Although built for libraries like Babel and Meteor, the same workflow applies to app codebases with numerous components. It allows you to sidestep the cumbersome task of extracting UI component packages out of your apps and into new repos in order to distribute on NPM.
• Pinpoint place: Trace which components are used by which apps so that developers can identify who made what and where. Electrode Explorer by @WalmartLabs is a good start.
• Orchestrate updates: Updates are one part notification (what needs to be updated) and one part integration (does the update break my app). In order to share UI changes automatically, visual integration tests are necessary. Visual snapshot testing is a step in the right direction.