strict: false

TypeScriptJunior~3 min read

What `strict: true` does

When tsconfig.json has:

javascript

{
  "compilerOptions": {
    "strict": true
  }
}

TypeScript enables the whole set of strict checks that make it a genuinely safe language, not just type highlighting.

"strict": true is a combo flag that turns on all the strict checks at once (equivalent to a set of options):

javascript

{
  "strict": true
}

≡ enables:

noImplicitAny
strictNullChecks
strictBindCallApply
strictFunctionTypes
strictPropertyInitialization
noImplicitThis
alwaysStrict

Why TypeScript without `strict` makes almost no sense

Because the whole point of TypeScript is to guarantee type safety. If strict is off, TypeScript stops doing that.

It starts guessing about types, allows implicit any, and does not check the most common sources of bugs (for example, null, undefined, argument mismatches, and so on).

In other words:

Without strict, TypeScript ≈ JavaScript + types "for show".

1. Without `noImplicitAny`, typing loses its point

javascript

function sum(a, b) {
  return a + b;
}

Without strict → TypeScript treats a and b as any. You can call:

javascript

sum(2, "abc"); // OK

TypeScript will not warn you, even though the result is "2abc".

With strict: true:

javascript

function sum(a: number, b: number): number {
  return a + b;
}

Now:

javascript

sum(2, "abc"); // Type error

2. Without `strictNullChecks`, protection from `null` / `undefined` is lost

javascript

function greet(name: string) {
  console.log("Hi " + name.toUpperCase());
}

greet(undefined); // Runtime error

Without strict, TypeScript thinks:

"well, maybe undefined is fine"

With strictNullChecks: true:

Error: Argument of type 'undefined' is not assignable to parameter of type 'string'.

This is the main reason strict is needed - 60-70% of real bugs in JS are related to undefined.

3. Without `strictPropertyInitialization`, classes become unsafe

javascript

class User {
  name: string;

  greet() {
    console.log("Hi " + this.name.toUpperCase());
  }
}

new User().greet(); // this.name = undefined → runtime error

With strict: true:

Error: Property 'name' has no initializer and is not definitely assigned.

Now you must initialize the property in the constructor:

javascript

class User {
  name: string;
  constructor(name: string) {
    this.name = name;
  }
}

4. Without `strictFunctionTypes`, function compatibility can break

javascript

let fn: (a: string) => void;
fn = (a: any) => console.log(a); // should be forbidden

Without strict, TS treats this as normal - safety is lost when passing callbacks.

5. Without `noImplicitThis`, strange context errors are possible

javascript

function sayHi() {
  console.log(this.message);
}

sayHi.call({ message: "Hello" }); // ok
sayHi(); // this === undefined

Without strict, TypeScript will not check that this is undefined.

With strict you get an error:

'this' implicitly has type 'any'.

6. Without `alwaysStrict`, TS does not use JS strict mode

TypeScript stops compiling files with "use strict", which leads to more "relaxed" JavaScript behavior (for example, non-strict handling of this, delete, var, and so on).

7. Without strict, TS stops being "insurance"

Without strict, TS cannot guarantee the code is correct.

Example:

javascript

function processData(data) {
  return data.value.toFixed(2);
}

processData(null); // Runtime error

TypeScript will not even tell you that data could be null. With strict it warns immediately:

Object is possibly 'null'.

8. The `any` type becomes a virus

When strict is off, TypeScript often automatically substitutes any if it does not know the type.

javascript

let user; // implicit any
user.toUpperCase(); // runtime error

"Undetermined" types start spreading through the whole codebase.

With strict:

Error: Variable 'user' implicitly has an 'any' type.

9. When strict is on, the compiler helps you write reliable code

TypeScript starts:

checking every nullable case (null, undefined);
controlling property initialization in classes;
forbidding implicit any;
making functions contravariant (that is, incompatible on unsafe arguments);
helping the IDE offer safe autocomplete.

Example: a project without strict vs with strict

Scenario	Without `strict`	With `strict: true`
Unspecified types	implicitly `any`	error
`null` and `undefined`	pass without errors	error
Class properties without initialization	allowed	error
Errors in `this` context	not checked	checked
Type safety	minimal	high
IntelliSense	imprecise	precise
Runtime bugs	frequent	rare

10. A simple analogy

Without strict - TypeScript just adds coloring and autocomplete.

With strict: true - it becomes a real static analyzer that genuinely protects your code from 90% of typical JS bugs.

Short Answer

Interview ready

Premium

A concise answer to help you respond confidently on this topic during an interview.