The case for strict TypeScript in every Angular project

Every Angular project starts with a tsconfig.json file. Somewhere in that file is a strict flag. When it is set to true, the TypeScript compiler becomes dramatically more demanding about the code it accepts. When it is set to false -- or worse, when individual strict flags are cherry-picked -- the compiler stays quiet about problems that will eventually bite you in production.

This is not a theoretical debate. I have seen the same category of bugs show up in project after project, all of them preventable by a compiler flag that was sitting right there, turned off. If you are starting a new Angular project, enable strict mode on day one. If you are maintaining an existing one, this article makes the case for migrating.

What strict mode actually enables

The strict flag in tsconfig.json is a shorthand that activates a bundle of individual compiler options. Each one catches a different class of error. Understanding what they do helps you appreciate why the combination is so powerful.

strictNullChecks is arguably the most impactful. Without it, every variable in your codebase can be null or undefined at any time, and the compiler will not warn you. With it enabled, you must explicitly handle the possibility of null values. That single change eliminates an entire class of runtime errors -- the dreaded "Cannot read properties of undefined."

strictPropertyInitialization forces you to initialize class properties in the constructor or declare them as potentially undefined. In Angular, this matters because components often have properties that receive values from inputs or services. Without this flag, a property declared as user: User looks safe, but it is actually undefined until something assigns it. With the flag on, you write user: User | undefined or user!: User (the definite assignment assertion), making the intent explicit.

noImplicitAny prevents you from accidentally using the any type. When a function parameter has no type annotation, TypeScript infers any, which effectively disables type checking for everything that touches that parameter. With noImplicitAny enabled, the compiler forces you to be explicit. You can still use any when you genuinely need it, but you have to opt in deliberately.

The bundle also includes strictFunctionTypes, strictBindCallApply, and noImplicitThis. Together, these flags close the most common gaps where TypeScript silently lets bugs through.

Real bugs that strict mode catches

Abstract descriptions only go so far. Here are concrete scenarios I have encountered in real Angular projects where strict mode would have caught the bug before it shipped.

A component displayed user profile data. The developer declared a property profile: UserProfile and populated it in ngOnInit from an HTTP call. The template used profile.email directly. On fast connections, this worked fine. On slow connections, the component rendered before the HTTP call resolved, and the template threw a runtime error trying to access email on undefined. With strictPropertyInitialization enabled, the compiler would have flagged the uninitialized property, forcing the developer to handle the loading state explicitly.

In another project, a service method accepted a parameter without a type annotation. It worked during initial development because the method only received strings. Three months later, another developer called the same method with a number. No compiler error. The method silently produced garbage output that took two days of debugging to trace. With noImplicitAny, the original developer would have been forced to type the parameter, and the second developer would have seen a type error immediately.

A third case involved an optional chaining oversight. A developer accessed config.settings.theme without checking whether settings existed. The config object came from an API response that sometimes omitted the settings field. Without strictNullChecks, TypeScript said nothing. With it, the compiler would have required either optional chaining or an explicit null check.

Why strict mode makes AI-generated code safer

This is the angle that most articles about strict TypeScript miss entirely, and in 2026 it might be the most important one. If you use Cursor or any other AI code assistant, strict mode acts as a safety net for generated code.

AI assistants generate code fast. They produce reasonable-looking functions, services, and components in seconds. But they do not run the code. They do not test it. They generate what looks right based on patterns, and patterns sometimes have gaps.

Without strict mode, the AI can generate a function that takes an untyped parameter, accesses a property that might be null, and returns a value that could be undefined. The editor shows no errors. You accept the suggestion, move on, and the bug sits there waiting.

With strict mode, those same AI-generated suggestions immediately show red squiggly lines. The compiler catches what the AI missed. You see the problem before you even save the file. The fix takes seconds because the error message tells you exactly what is wrong -- this property might be undefined, this parameter needs a type, this return value does not match the declared type.

In practice, this creates a powerful workflow. The AI generates code quickly. The compiler validates it instantly. You fix the small gaps the AI left. The result is code that is both fast to write and genuinely type-safe. Without strict mode, the AI's mistakes pass silently into your codebase.

The "it's too noisy" objection

I hear this one all the time. "We tried strict mode and it was hundreds of errors. We turned it off." I understand the frustration. Enabling strict mode on a large existing project does produce a wall of compiler errors. But calling it "too noisy" misunderstands what those errors represent.

Each error is a place in your code where a type is wrong, incomplete, or ambiguous. The errors are not noise. They are a map of everywhere your type safety has gaps. The code was always this loose -- strict mode just made it visible.

The real objection is not that strict mode is noisy. It is that fixing hundreds of errors at once feels overwhelming. That is a valid concern, and there is a practical solution: you do not have to fix them all at once. TypeScript lets you enable strict flags individually. Start with noImplicitAny because it produces the fewest errors in most projects. Fix those. Then enable strictNullChecks. Fix those. Work through the flags one at a time until you can enable the full strict shorthand.

Teams that push through the initial discomfort universally report the same thing: fewer bugs in production, faster code reviews, and more confidence when refactoring. The noise was temporary. The benefits are permanent.

Practical steps to enable strict mode in an existing project

If you are convinced and want to start, here is the approach I recommend. It is designed to be incremental so you never have to stop feature work to do a massive type-fixing sprint.

First, create a branch dedicated to strict mode migration. Open your tsconfig.json and add "noImplicitAny": true to the compiler options. Run ng build and count the errors. If there are fewer than fifty, fix them in one sitting. If there are more, use a // @ts-expect-error comment on the worst offenders and create tickets to address them over the next few sprints.

Once noImplicitAny is clean, move to strictNullChecks. This one usually produces more errors because it touches every place where null and undefined are not handled. The same incremental approach works. Fix what you can, suppress what you cannot fix immediately, and chip away at the suppressions over time.

After null checks, enable strictPropertyInitialization. In Angular projects, this one often requires adding the definite assignment assertion (!) to properties decorated with @Input() in older-style components, or refactoring to use the input() signal function which handles initialization more elegantly.

Once all individual flags pass cleanly, replace them with the single "strict": true shorthand. This ensures you automatically pick up any new strict flags that TypeScript adds in future versions.

Strict mode and your cursor rules

If you use Cursor with cursor rules for your Angular project, add a line to your rules file that says "this project uses TypeScript strict mode." It sounds simple, but it changes the AI's behavior. When Cursor knows strict mode is enabled, it generates code that handles null checks, types parameters explicitly, and initializes properties correctly. Without that instruction, the AI often takes shortcuts that strict mode would reject.

You can go further. Add rules like "never use the any type unless there is a comment explaining why" or "prefer unknown over any for untyped API responses." These rules work hand in hand with the compiler flags. The rules tell the AI what to aim for. The compiler catches what the AI misses. Together, they produce code that is more type-safe than either one achieves alone.

The Angular Cursor Rules Builder includes strict mode preferences in its generated output. If you tell it your project uses strict TypeScript, the generated rules file includes instructions that guide the AI toward strict-compatible code patterns. It is one checkbox that improves every AI interaction in your project.

Strict TypeScript is not about being pedantic. It is about catching problems at the earliest possible moment -- in the editor, before the code is saved, before the tests run, before the PR is opened. Every bug caught by the compiler is a bug that never reaches your users. In a world where AI writes an increasing share of our code, that safety net is more valuable than ever.