Consider an Angular app where a component is declared but never used in any template or routing. What happens to this component during the build process with tree shaking enabled?
Think about what tree shaking means for unused code.
Tree shaking removes code that is not referenced anywhere in the app. Since the component is never used, it is removed from the final bundle, reducing bundle size.
Given a utility library with many functions, which import style allows Angular's build tools to remove unused functions effectively?
Consider how named imports vs namespace imports affect static analysis.
Named imports allow the build tools to detect exactly which functions are used and remove the rest. Namespace imports or side-effect imports prevent effective tree shaking.
Look at this Angular service code snippet:
export class DataService {
fetchData() { return 'data'; }
unusedMethod() { return 'unused'; }
}Despite unusedMethod never being called, it remains in the final bundle. Why?
Think about how Angular includes services provided in root.
When a service is provided in root, Angular includes the entire class in the bundle. Tree shaking does not remove unused methods inside classes because the class is referenced as a whole.
How does Angular's Ivy compiler improve tree shaking and dead code removal compared to the previous View Engine?
Think about how code generation affects static analysis.
Ivy generates smaller, more modular code that allows build tools to detect and remove unused components and code more effectively than the older View Engine.
In an Angular app, you import a large feature module but never use any of its components or services. What happens to the final bundle size after build with tree shaking?
Consider how Angular treats imported modules even if unused.
Importing a module causes Angular to include its code in the bundle. Tree shaking cannot remove the module because it is referenced by the import statement, even if its components are unused.