Exercise 3: Why Security Fixes Don't Propagate, and the Responsibility This Shifts — Possible Solution ==================================================================== WHY A SECURITY FIX UPSTREAM DOESN'T AUTOMATICALLY REACH A PROJECT THAT ALREADY COPIED AN EARLIER VERSION ------------------------------ Per this chapter's own warn-box, "since shadcn/ui components become literal owned code with no ongoing dependency relationship, a real security or accessibility fix discovered in the upstream shadcn/ui project does not automatically reach a project that already copied an earlier version." Per this chapter's own earlier material, once a component has been copied into a project via the CLI, "that file IS the project's own code" — there is no longer any structural connection back to the original upstream shadcn/ui source at all. If the upstream shadcn/ui project later discovers and fixes a real bug (including a security or accessibility bug) in that same component, the fix exists only in the UPSTREAM project's own repository — nothing in a project that already copied the OLDER version has any mechanism to detect that a fix even exists, let alone automatically receive it, because the copied file is now indistinguishable from any other hand-written project code, with no version number or dependency link tracking it back to its original source. WHY THIS DIFFERS FROM A TRADITIONAL NPM DEPENDENCY ------------------------------ Per this chapter, "unlike a traditional npm dependency, where npm audit or automated dependency-update tooling can flag and help apply security fixes, an owned, copied component requires the team to actively, manually track upstream changes themselves." A traditional npm dependency remains a distinctly-versioned, externally-tracked package throughout its life — tools like npm audit can compare a project's own currently-installed version against a database of known vulnerabilities and flag exactly when an update is needed, and applying that update is often as simple as running an update command. None of that tooling has anything to detect or act on here, since a copied shadcn/ui component isn't tracked as a versioned dependency at all anymore. THE REAL RESPONSIBILITY THIS SHIFTS ONTO THE ADOPTING TEAM ------------------------------ Per this chapter, this is "a genuine, real operational responsibility this model shifts onto the adopting team." Rather than relying on automated tooling to surface known vulnerabilities the way a traditional dependency model allows, a team using shadcn/ui-style copied components has to take on the ongoing, MANUAL responsibility of actively watching the upstream project for security or accessibility fixes themselves, and then manually re-applying those fixes to their own already-customized copies — a genuinely real, ongoing maintenance burden with no equivalent in the traditional dependency model. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains the specific structural reason (no version/dependency link remaining after the copy) that prevents automatic fix propagation, contrasts this against what traditional dependency tooling like npm audit actually provides, and states the specific ongoing responsibility the chapter says shifts onto the adopting team as a result.