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 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.

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

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.