A team puts 'use client' at the top of a shared components/index.js barrel that re-exports their whole component library, and the client JavaScript bundle grows sharply. Explain the mechanism, and how you would restructure the boundary.

## What actually happened The directive is not an annotation on a component; it marks a module as an entry point into the client graph, and everything reachable from that module by `import` goes with it. A barrel file is, by construction, a module that imports everything: ```js // components/index.js 'use client'; export { Button } from './Button'; export { Chart } from './Chart'; export { MarkdownArticle } from './MarkdownArticle'; // ...forty-seven more ``` One line has now declared the entire library client code. `MarkdownArticle` pulled in a markdown parser and a syntax highlighter; `Chart` pulled in a charting package. None of that was ever interactive, and all of it is now downloaded and hydrated by the browser. Two effects compound: 1. **Weight.** The transitive dependency closure of the barrel becomes the client bundle floor. Even where tree-shaking prunes exports nobody uses, everything actually reached is on the client side of the line, and any module with import-time side effects resists shaking entirely. 2. **Lost capability.** Components below the boundary can no longer be server components. A component that used to `await` a data source directly must now fetch over the network from the browser instead, and any module that reaches server-only configuration or credentials is suddenly in a graph that gets shipped — a correctness and secrecy problem, not just a size one. The reason this is a favourite interview scenario is that it never announces itself. The app keeps working. Nothing errors. The only symptom is a bundle report and a slower page. ## How to confirm the diagnosis Before restructuring, establish the causal chain rather than guessing. The evidence you are looking for: - Which modules are in the client bundle that you did not expect — a bundle analysis of the client chunks, compared against the previous release. - Which import path put them there — trace back from a surprising module to the nearest ancestor carrying `'use client'`. In this scenario every path leads through the barrel. - Whether any of those modules were server components before. Those are the ones that lost capability, not just weight. Stating this diagnostic step is what separates a senior answer from a middle one: the fix is obvious once the mechanism is known, and the skill is in proving the mechanism from the artifacts. ## The restructuring **1. Take the directive off the barrel.** Barrels, and shared utility modules generally, should carry no directive at all. A directive-free module can be imported from a server component or from a client component; it takes its side from whoever imports it. That flexibility is exactly what you want in shared code. **2. Mark the leaves.** Put `'use client'` on the smallest module that genuinely needs it — the one that calls `useState`, attaches an `onClick`, reads a ref, or subscribes to something in the browser. A library of fifty components usually has a handful of these. ```js // components/Button.js 'use client'; import { useState } from 'react'; export function Button(props) { /* ... */ } ``` **3. Split mixed modules.** A file that exports both an interactive control and a heavy non-interactive renderer cannot be marked either way without harm. Split it so the interactive part lives alone in its marked module. **4. Invert the wrappers.** Where an interactive shell sits above a large content subtree, stop importing the content into the shell and pass it in as `children` from a server parent instead. The shell becomes a hole; the content stays on the server. This is the highest-leverage single move when the interactive part is small and the content is large. **5. Reconsider the barrel itself.** Barrels are convenient and structurally hostile to boundaries: a single import site reaches the whole library, and any future directive added anywhere near the barrel repeats this incident. Importing components from their own modules — or splitting one barrel into a client-side and a server-side entry — removes the shared choke point. ## Preventing the recurrence The durable fix is not the edit, it is the rule. Treat a directive on any widely imported module as a change with a measurable cost: it needs a bundle-size number attached, the same way a new dependency does. A client-bundle budget checked in CI turns the next occurrence into a failed build rather than a slow page discovered a quarter later. And in review, the question to ask of any new `'use client'` is simply "what is below this line?" — because that, and not the file it is written in, is what the directive actually selects.