Packaging a design system as an npm dependency
Distributing shared code as a versioned package.
publish to an npm registry, with package.json holding the version, entry points, and dependencies, and version it via SemVer.
What's really being asked
This checks baseline knowledge of how shared frontend code is distributed and versioned across projects, and which file governs the version contract.
The full answer
The standard approach is to publish the design system as an npm package to a registry, either the public npm registry or a private one such as a company registry or GitHub Packages, possibly under a scope. Consuming projects then add it as a dependency and install it with their package manager. The crucial file is package.json. Its version field is the single source of truth for the package version and must follow semantic versioning, major dot minor dot patch. Other fields matter too: name identifies the package, main and module and the modern exports map define entry points for CommonJS and ES modules, types points to TypeScript declarations, files or an ignore file controls what gets published, peerDependencies declares shared libraries like React so consumers do not get duplicates, and sideEffects helps tree-shaking. A lockfile pins exact resolved versions for reproducible installs.
The mistakes people make
Suggesting copy-paste between repos creates drift and no version history. Git submodules are fragile and lack proper version ranges. Bundling React as a hard dependency rather than a peer dependency risks multiple React copies. Forgetting to set the files allowlist can publish source or tests by accident.
What usually comes next
How do you bump the version, and what does each SemVer segment mean? What are peerDependencies for? How do you publish a private package and control access? What is the difference between a caret and tilde range in a consumer? How does the exports field support dual ESM and CJS?
A concrete example
A company publishes acme-ui at version 2.4.1 to its private registry, with React listed as a peer dependency and an exports map for ESM and types. A product app adds it with a caret range, so npm install pulls 2.4.x patches automatically, and the team bumps the version in package.json on each release.
Interview question
Why is React typically declared as a peerDependency rather than a regular dependency in a published component library?
- a.Because peerDependencies are installed automatically without prompting
- b.To make the library install faster for consumers
- c.To avoid bundling a second copy of React alongside the consumer's ownCorrect
- d.Because regular dependencies are not allowed in libraries
Why? this is the answer
A peerDependency signals that the consumer supplies React, preventing duplicate React instances that break hooks and context. A regular dependency could install a second copy. Peer deps are not about install speed and are allowed alongside normal deps.
Just read this? Test yourself on what you have been reading.
Read the original → docs.npmjs.com
- #npm
- #packaging
- #semver
- #package-json
- #design-systems
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on npm — each one lists the topics its interview covers.
See open roles