Standalone by Default: The v15 to v19 Arc In short: Standalone components took four versions to go from optional to default. A project can be stuck at any of those stages, and the work to move forward is different at each one. The four stages v14 (2022) — early preview. existed and worked, but other libraries did not support it and the CLI did not create it. v15 (Nov 2022) — safe to use, but optional. The APIs became final. became the recommended way to start an app. Every component still needed the flag written out. v17 (Nov 2023) — the CLI default. made a standalone app. New components came with . Existing code was left alone. v19 (Nov 2024) — the language default. became pointless and was removed from new files. Anything that still needs a module has to say . That last flip surprises people reading unfamiliar code. From v19, a component with no setting at all is standalone. A component that is not standalone has to announce it: The tool does the real work Angular ships helper scripts for this, and unlike many automatic tools, these do the heavy lifting. Run them in this order: The same command runs in three modes and asks you to pick one each time. Run them in that order, commit after each, and run your tests in between. What it will not do is redesign anything. If you had a exporting forty components, you will get forty entries in the list of every component that used it. That is correct — and it is also a signal. Those components were never using forty things. The problem Nearly every module-based project has one, and it is the hardest part of the move. The tempting fix is to make a standalone version of the same thing — a list you spread into every component: It compiles. It keeps the convenience. And it throws away the whole point. The compiler can no longer tell what a component actually uses. So it cannot warn about unused imports, and it cannot remove unused code properly. You have rebuilt with extra steps. The better move is to let the tool produce the long explicit lists, then trim them. A component that imports three things is telling you something true. Where a grouping is genuinely real, keep it small and name it for a purpose: When a module is still right Two cases survive. Library support. If you publish a library used by apps that still use modules, you may need to ship an wrapper next to your standalone components. Standalone components can go inside a module's , so this is a thin layer, not a second version. Moving a big codebase slowly. Standalone and module code work together in both directions . A standalone component can be listed in a module's . A module-based component can be used by a standalone one if you import its module. That two-way support is what makes a gradual move possible. There is no single scary switchover day. What is not a good reason: "we like the structure." Folders give you that, without a file you have to keep updated. "But won't the imports lists be huge?" This is the most common worry, and it is why teams reach for the spread-everywhere list that undoes the whole thing. The worry is understandable, but think about what actually goes into that list. disappears completely, because control flow is built into the language now. is only needed where there is actually a form. becomes and , imported only where used. A component that once imported four modules to get , , a pipe and a child component now imports one thing: the child component. And a long list is useful information, not noise. A component with twelve imports is telling you it does twelve things. You could never see that before, because looked identical whether the component used one export or forty. The other worry — "we lose our structure." Modules gave you four things (last lesson). Only privacy is truly lost. Folders still group code, and boundaries move to a tool: The architect's view The decision you are actually making is where dependency information lives: in a shared list that nothing verifies, or on each component where the compiler can check it. Why explicit imports win. Angular's docs state the mechanism plainly: a standalone component's array holds what its own template uses. That has three consequences worth caring about as an architect. Correctness is checked. An unused entry in a component's is a build error. An unused entry in a module's was invisible. You get a compiler-enforced accuracy guarantee you did not have before. Bundling gets accurate. When the dependency graph is per-component instead of per-module, the build tool can see exactly what a screen needs. A forced everything it exported into the graph of everything that imported it. The code documents itself. "What does this component depend on?" becomes a question you answer by reading the component. What it costs. Longer arrays, and real effort unpicking a by hand. Budget for that honestly — it is the one genuinely manual part of the standalone migration. The trap that wastes the effort. Replacing with and spreading it everywhere…