@tsconfig/strictest#

@tsconfig/strictest is a shared tsconfig preset that turns on basically all the serious safety flags. Think of it as:

"strict": true + “all the extra little things you probably should have enabled but didn’t”.

You don’t have to remember every flag like noImplicitAny, noUncheckedIndexedAccess, exactOptionalPropertyTypes, etc. You just extend this preset and get a “maximum safety” TypeScript config by default.

@total-typescript/ts-reset#

ts-reset is a “standard library reset” for TypeScript.

It doesn’t change your runtime JS at all. It changes how TypeScript types built-ins:

• JSON.parse
• Array.prototype.filter(Boolean)
• includes
• Object.keys, etc.

It fixes a bunch of places where TS is either too loose (any) or not smart enough, and makes them safer and more predictable.

1. Install and extend @tsconfig/strictest#

1
npm i -D @tsconfig/strictest
2
# or pnpm add -D @tsconfig/strictest
3
# or yarn add -D @tsconfig/strictest

Then in tsconfig.json:

1
{
2
  "extends": "@tsconfig/strictest/tsconfig.json",
3
  "compilerOptions": {
4
    // your custom stuff here
5
    "lib": ["ES2022", "DOM"],
6
    "module": "ESNext",
7
    "moduleResolution": "node"
8
  },
9
  "include": ["src"]
10
}

Boom — all the strict flags I’d been too lazy to configure are now on.

2. Install and import ts-reset#

1
npm i -D @total-typescript/ts-reset

Then, in the app entry file (whatever runs first, like src/main.ts or similar):

1
// Must be the first import
2
import "@total-typescript/ts-reset";

After these two steps, my editor turned into a “type-safety review” mode. Let’s look at what actually changed.

Example 1 – “I’ll type it later” helper functions#

Old code in my personal project:

1
export const getUserDisplayName = (user) => {
2
  if (!user) return "Anonymous";
3

4
  if (user.firstName || user.lastName) {
5
    return `${user.firstName ?? ""} ${user.lastName ?? ""}`.trim();
6
  }
7

8
  return user.email ?? "Anonymous";
9
};

This compiled fine before. With @tsconfig/strictest:

• noImplicitAny complains about user.
• strict null checks complain about optional fields.
• The return type is inferred but not guaranteed anywhere.

So I fixed it:

1
type User = {
2
  firstName?: string | null;
3
  lastName?: string | null;
4
  email?: string | null;
5
};
6

7
export const getUserDisplayName = (user: User | null): string => {
8
  if (!user) return "Anonymous";
9

10
  if (user.firstName || user.lastName) {
11
    return `${user.firstName ?? ""} ${user.lastName ?? ""}`.trim();
12
  }
13

14
  return user.email ?? "Anonymous";
15
};

Now:

• Callers see clearly that user can be null.
• The function always returns a string.
• If I change the User type later, the compiler guides me.

This pattern then went back into our main project: anytime we had “utility functions” with weak types, strictest helped force us to define the contract properly.

Example 2 – Object maps with missing keys#

I had a small config map like this:

1
const labels = {
2
  home: "Home",
3
  profile: "Profile",
4
};
5

6
function getLabel(route: "home" | "profile" | "settings") {
7
  return labels[route];
8
}

This kind of “almost correct” code compiled before.

With @tsconfig/strictest, flags like noUncheckedIndexedAccess and stricter indexing made this unsafe:

• route can be "settings", but labels.settings doesn’t exist.
• The index access can be undefined.

So the compiler complained, and I refactored:

1
const labels: Record<RouteName, string> = {
2
  home: "Home",
3
  profile: "Profile",
4
  settings: "Settings", // ✅ compiler forces me to handle all cases
5
};
6

7
type RouteName = "home" | "profile" | "settings";
8

9
function getLabel(route: RouteName): string {
10
  return labels[route];
11
}

Or with satisfies:

1
const labels = {
2
  home: "Home",
3
  profile: "Profile",
4
  settings: "Settings",
5
} satisfies Record<RouteName, string>;

Suddenly I can’t “forget” a key without TS warning me — which is exactly what you want in real projects when you add new routes or statuses.

Example 3 – JSON.parse pretending to be safe#

Originally, I had this in my personal project:

1
const raw = localStorage.getItem("user");
2
const user = raw ? JSON.parse(raw) : null;
3

4
console.log(user.name.toUpperCase());

Default TS types:

• JSON.parse returns any.
• user is any or null.
• TypeScript silently allows user.name.

With ts-reset, JSON.parse returns unknown, so the compiler forces me to be explicit.

I changed it to:

1
type User = {
2
  id: string;
3
  name: string;
4
};
5

6
const raw = localStorage.getItem("user");
7
const user: User | null = raw ? (JSON.parse(raw) as User) : null;
8

9
if (!user) {
10
  // handle not logged in
11
} else {
12
  console.log(user.name.toUpperCase());
13
}

Later, I wrapped it in a helper, but I realised that just using as T wasn’t much better than any. A type assertion is basically telling TypeScript:

“Trust me, it’s definitely a T.”

…without doing any runtime validation:

1
function parseJson<T>(value: string | null): T | null {
2
  if (!value) return null;
3
  return JSON.parse(value) as T; // ⚠️ No actual validation
4
}
5

6
const user = parseJson<User>(localStorage.getItem("user"));

This is nicer to use, but it’s still unsafe if the JSON in storage doesn’t match User at all.

In reality, the wrapper should also validate what it parses. That can be as simple as a few sanity checks:

1
function parseUser(value: string | null): User | null {
2
  if (!value) return null;
3

4
  const parsed: unknown = JSON.parse(value);
5

6
  // validation logic
7

8
}

For real-world projects and more complex types, you don’t want to hand-roll these checks everywhere. That’s where a schema/validation library like Zod shines: you define the shape once, and reuse it for both runtime validation and TypeScript types.

This pattern then migrated back into our main project for:

• localStorage,
• feature flags,
• cached API responses.

ts-reset basically refused to let me pretend that JSON.parse always returns what I think.

Example 4 – .filter(Boolean) and weird arrays#

I had this classic snippet:

1
const ids = ["1", undefined, "2", null, "3"];
2

3
const clean = ids.filter(Boolean);
4

5
clean.forEach((id) => {
6
  doSomethingWithId(id);
7
});

In my head:

“clean is an array of strings, obviously.”

In TypeScript’s default world: inference is not always “obviously string[]”.

ts-reset improves the typing of .filter(Boolean) so it matches what we mean:

1
const ids = ["1", undefined, "2", null, "3"];
2

3
const clean = ids.filter(Boolean);
4
// clean: string[]
5

6
clean.forEach((id) => {
7
  // id: string
8
  doSomethingWithId(id);
9
});

Same code style, but now the types line up with reality. This showed up in a lot of places in my old code where I filtered out nulls/undefined.