How I Fixed My TypeScript Setup Issue: Property user does not exist on type Request.

Nikhil Agrawal — Sat, 14 Sep 2024 19:00:28 +0000

The Problem
I’ve been working on a Node.js project with TypeScript and Express.js. At one point, I needed to attach a user object to the Express Request object, but I ran into this TypeScript error:

Property 'user' does not exist on type 'Request'.

I quickly realized that this happens because Express's default Request object doesn't include a user property, and TypeScript wasn’t happy about it.

My Initial Fix
To fix this, I extended the Request interface to add the user property. Here’s how I did it:

I created a new file called express.d.ts in the types folder in my project:

// src/types/express.d.ts
import { User } from '@prisma/client'; // Assuming User is a Prisma model

declare global {
    namespace Express {
        interface Request {
            user?: User; // Add user to the Request interface
        }
    }
}

I updated my tsconfig.json to ensure TypeScript picked up this new type:

{
  "compilerOptions": {
    //extra options here
    "typeRoots": ["./node_modules/@types", "./src/types"] // Add the types folder
  }
}

At this point, the error disappeared from my code editor, so I thought I had fixed the problem. But when I tried running the project, I hit another error in the terminal:

error TS2339: Property 'user' does not exist on type 'Request'.

Stuck for Days
I spent 3-4 days troubleshooting this, trying everything I could find online. I was completely stuck and couldn’t figure out why it wasn’t working.

The Solution
Finally, I discovered the root issue and fixed it with these steps:

Install TypeScript Globally: I realized I didn’t have the TypeScript compiler (tsc) installed globally, so I ran this command:

npm install -g typescript

Run the TypeScript Compiler in Watch Mode: I used the --watch flag to automatically recompile my TypeScript code as I worked:
tsc --watch
Restart My Code Editor: I restarted my editor (VS Code in my case) to make sure everything was loaded properly.
Run the Project: After restarting, I ran the project again—and it worked!

Conclusion
What I thought would be a small issue turned into days of frustration, but I finally got it working! If you're facing similar problems with TypeScript not recognizing new properties on Express’s Request object, remember to:

Extend the Request interface correctly.
Make sure TypeScript’s compiler (tsc) is installed and running properly.
Hopefully, this helps anyone else who's been stuck like I was!

Try...Catch V/s Safe Assignment (?=): A Boon or a Curse for Modern Development?

Nikhil Agrawal — Sun, 25 Aug 2024 18:27:57 +0000

Recently, I discovered the new Safe Assignment Operator (?.=) introduced in JavaScript, and I’m really fascinated by its simplicity. 😍

The Safe Assignment Operator (SAO) is a shorthand alternative to the traditional try...catch block. It lets you catch errors inline without writing explicit error-handling code for each operation. Here’s an example:

const [error, response] ?= await fetch("https://api.example.com/data");

That’s it! It’s that easy. If the fetch request throws an error, it’s automatically stored in the error constant; otherwise, the response holds the result. Pretty cool, right?

But wait… there’s more.

When using SAO, you still have to handle errors further down the line, like this:

async function getData() {
  const [requestError, response] ?= await fetch("https://api.example.com/data");

  if (requestError) {
    handleRequestError(requestError);
    return;
  }

  const [parseError, json] ?= await response.json();

  if (parseError) {
    handleParseError(parseError);
    return;
  }

  const [validationError, data] ?= validation.parse(json);

  if (validationError) {
    handleValidationError(validationError);
    return;
  }

  return data;
}

While SAO simplifies error handling, it can lead to more verbose code. Compare that with a traditional try...catch block:

async function getData() {
try {
  const response = await fetch("https://api.example.com/data");
  const json = await response.json();
  const data = validation.parse(json);
  return data;
} catch (error) {
  handleError(error);
  return;
}
}

In this case, try...catch takes only 9 lines of code, while SAO approximately double of it.

So, what do you think? Is the Safe Assignment Operator a time-saver, or does it add unnecessary complexity?

Forem: Nikhil Agrawal

How I Fixed My TypeScript Setup Issue: Property user does not exist on type Request.

Try...Catch V/s Safe Assignment (?=): A Boon or a Curse for Modern Development?