Exercise 1: npm Dependency vs. shadcn/ui's "Copy, Don't Install" Model — Possible Solution ==================================================================== THE TRADITIONAL NPM DEPENDENCY MODEL ------------------------------ Per this chapter, "using a component library... means installing it as a normal npm dependency. The component's own source code lives inside node_modules, is treated as external, third-party code, and is updated by bumping a version number. The developer never directly edits the library's own source." In this model, the component library remains a genuinely SEPARATE thing from the project's own codebase — it lives in a special, external folder, is never directly modified by the project's own developers, and any change to the library's own behavior arrives by upgrading a version number, pulling in whatever new code the library's own maintainers published. SHADCN/UI'S OWN "COPY, DON'T INSTALL" MODEL ------------------------------ Per this chapter, "rather than installing shadcn/ui as a dependency, its own CLI tool copies the actual component source code... directly into the project's own codebase. The component becomes literal, owned, editable project code, not an external dependency at all." Per this chapter's own example, running a command like npx shadcn-ui add button generates a real, actual button.tsx file directly inside the project's own components folder. From that point on, per the chapter, "that file IS the project's own code, indistinguishable from anything hand-written" — there's no external node_modules relationship left at all; the component is now ordinary, first-party project code that developers can read, edit, and modify freely, exactly like anything they wrote themselves. THE FUNDAMENTAL DIFFERENCE ------------------------------ The core difference is whether the component's own code remains EXTERNAL (owned and maintained by someone else, referenced but never edited) or becomes INTERNAL (physically copied into the project, immediately becoming the project's own first-party code with no ongoing relationship to its original source). This single structural difference is what produces every other trade-off this chapter discusses — how updates work, how customization works, and who's responsible for security fixes. WHY THIS WORKS AS AN ANSWER ------------------------------ It states both models precisely using the chapter's own wording and its own concrete CLI example, and identifies the single core structural distinction (external vs. now-internal code) underlying both models, rather than just listing surface differences.