Struggling with TypeScript errors when adding dynamic properties to an object? As a senior engineer, I’ll walk you through why it happens and three real-world solutions, from the quick-and-dirty fix to the proper, scalable pattern.

So You Want to Dynamically Add Keys to an Object in TypeScript? Let’s Talk.

It was 2 AM. PagerDuty was screaming. A critical log processing script running on prod-db-01 was failing. A new service, auth-service-v2, had just come online and was sending a slightly different log format, including a new traceId we desperately needed. A junior engineer, trying to be helpful, had patched the script to just “tack on” the new property to a generic object. The TypeScript build pipeline had, of course, thrown a fit: Property 'traceId' does not exist on type 'object'. But in a rush to deploy, the check was manually overridden. The result? A runtime crash that took down our entire log ingestion pipeline for an hour. That night reminded me that this isn’t just an annoying compiler error; it’s a foundational concept that separates a junior from a senior.

First, Why is TypeScript So Mad at Me?

Let’s get one thing straight: TypeScript isn’t being difficult for the sake of it. It’s trying to save you from yourself. When you declare something as a generic object, you’re telling TypeScript, “This is a thing, but I’m giving you zero details about its shape, its properties, or what it contains.”

So when you then try to do this:

const myConfig = {}; // Inferred as '{}', an object with no properties
myConfig.hostname = 'prod-api-03'; // Error! Property 'hostname' does not exist on type '{}'.

TypeScript throws up its hands and says, “Whoa, hold on! You never told me this thing was supposed to have a hostname property. For all I know, you made a typo, and this is going to cause a nasty undefined error at runtime.” It’s protecting the structural integrity of your code. It demands a blueprint, a contract, for what an object should look like.

Okay, I Get It. How Do I Fix It?

We’ve all been in a situation where we need to build an object on the fly—parsing environment variables, aggregating results from multiple API calls, you name it. Here are the three ways I approach this, from the “fire-is-raging” fix to the “let’s build this to last” solution.

Solution 1: The Quick & Dirty (The ‘any’ Escape Hatch)

This is the one most people find first. You tell TypeScript to just look the other way by using the any type. It effectively disables all type-checking for that variable.

const dynamicData: any = {};

dynamicData.userId = 123;
dynamicData.status = 'active';
dynamicData.lastLogin = new Date();

console.log(dynamicData.lastlogin); // Oops, a typo. TypeScript says nothing. This will be 'undefined' at runtime.

Darian’s Take: Using any is like taking the battery out of a smoke detector because it chirped once. It solves the immediate annoyance but defeats the entire purpose of having the safety system in the first place. I only ever use this for a true emergency hotfix or when interfacing with a horribly typed third-party library where I have no other choice. Use with extreme caution.

Solution 2: The Right Way (The Index Signature)

This is the idiomatic, professional TypeScript solution. You tell the compiler, “I don’t know the exact names of the keys ahead of time, but I *do* know they will all be strings, and their values will be of a certain type.” This is called an index signature.

You can define it in an interface or a type alias:

// Define the "shape" of our dynamic object
interface ApiMetrics {
  [key: string]: number | string; // All keys are strings, values are number or string
}

const metrics: ApiMetrics = {};

metrics.requests = 1052;
metrics.endpoint = '/v1/users';
metrics.status_code = 200; // Whoops, typo!
// TypeScript Error: Property 'status_code' does not exist on type 'ApiMetrics'. Did you mean 'statusCode'?
// This assumes you also defined 'statusCode' as an optional property. Even without it, this enforces the value type.

A more direct, inline way uses the Record utility type, which is just a cleaner syntax for the same thing:

const serverConfig: Record<string, any> = {};

serverConfig.ipAddress = '10.0.1.55';
serverConfig.port = 8080;
serverConfig.isProduction = true;

Here, Record<string, any> is a great general-purpose tool, but for better safety, try to be more specific than any, like Record<string, string | number | boolean>.

Solution 3: The “Trust Me, Bro” (Type Assertion)

Sometimes, you know more than the compiler. You might be initializing an empty object that you are about to immediately populate in a loop. In these cases, you can use type assertion with the as keyword. This is you telling TypeScript, “Look, I know this looks like an empty object right now, but trust me, it’s about to become a Record<string, string>. Just treat it as such from the get-go.”

// Let's say we're parsing process.env variables
const envConfig = {} as Record<string, string>;

for (const key in process.env) {
  if (key.startsWith('APP_')) {
    const value = process.env[key];
    if (value) {
      envConfig[key] = value;
    }
  }
}

Warning: This is a powerful tool, but it’s a loaded gun. If you assert a type and then fail to actually make the object match that type, TypeScript won’t save you. You’ve explicitly told it not to worry. Use this when you are 100% confident that the object will conform to the asserted type by the time it’s used.

My Final Two Cents

Here’s a quick cheat sheet for you.

We’ve all been that junior dev staring at a “Property does not exist” error, feeling frustrated. The key is to stop fighting the compiler and start listening to it. It’s not your enemy; it’s your most vigilant pair programmer. Understanding why it’s complaining is the first step. Choosing the right tool to satisfy it is what makes you a senior engineer.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions