Suggest an edit

Improve this article

Refine the answer for “strict: false”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

## What `strict: true` does

When `tsconfig.json` has:

```javascript
{
  "compilerOptions": {
    "strict": true
  }
}
```

- TypeScript turns on **the entire set of strict checks** that make it **an actually safe language**, not just type highlighting.

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

```javascript
{
  "strict": true
}
```

≡ turns on:

- `noImplicitAny`
- `strictNullChecks`
- `strictBindCallApply`
- `strictFunctionTypes`
- `strictPropertyInitialization`
- `noImplicitThis`
- `alwaysStrict`

## Why TypeScript without `strict` is almost pointless

Because **the entire 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 type `any`. You can call:

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

> TypeScript will not warn you, even though the result will be `"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` you lose protection from `null` / `undefined`

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

greet(undefined); // Runtime error
```

Without `strict`, TypeScript thinks:

> "well, what if `undefined` is fine here"

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 → error at runtime
```

With `strict: true`:

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

Now you are required to initialize the property in the constructor:

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

## 4. Without `strictFunctionTypes` you can break function compatibility

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

> Without `strict`, TS treats this as normal: you lose safety when passing callbacks.

## 5. Without `noImplicitThis` you can get strange context bugs

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

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

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

With `strict` you will 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 a "safety net"

Without `strict`, TS cannot guarantee that 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 will warn you right away:

> Object is possibly 'null'.

## 8. The `any` type becomes a virus

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

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

> "undefined" types start spreading throughout 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 to:

- check every nullable case (`null`, `undefined`);
- control property initialization in classes;
- forbid implicit `any`;
- make functions **contravariant** (that is, incompatible on dangerous arguments);
- help the IDE offer safe autocompletion.

## Example: a project without strict vs with strict

| Scenario | Without `strict` | With `strict: true` |
|---|---|---|
| Unspecified types | implicit `any` | error |
| `null` and `undefined` | pass without errors | error |
| Class properties without initialization | allowed | error |
| Errors in the `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 syntax highlighting and autocompletion.
>
> With `strict: true`, it becomes **a genuine static analyzer** that actually protects your code from 90% of typical JS bugs.

Markdown · drag & drop images · ⌘B / ⌘I shortcuts787 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.