Well, I have to admit, I was a bit taken aback when I stumbled upon those namespaces buried in the legacy codebase last Tuesday. I mean, come on, Redux? That’s so 2020. But hey, you know what they say – one developer’s relic is another’s treasure. And as I dug a little deeper, I realized that these “IIFE-generating relics” might actually have a place in the modern TypeScript landscape.

Sure, the documentation practically yells at you to use ES Modules these days. But as I learned, namespaces aren’t just types – they actually generate JavaScript code, which can be pretty handy in certain situations. And with Node.js pushing the boundaries on native TypeScript support, I was pleasantly surprised to see these namespaces running smoothly without any build steps.

But the real epiphany came when I realized that namespaces are basically just objects. They create a nice, organized structure for your code, and they even have that nifty “declaration merging” feature that ES Modules can’t touch. I mean, come on, who doesn’t love a good $.ajax moment?

The One Thing Modules Can’t Do

And that’s where namespaces really shine. Sure, they might not be the flavor of the month, but they’ve got a few tricks up their sleeve that ES Modules can’t match. Like that whole “declaration merging” thing – it’s surprisingly useful, especially when you’re dealing with those pesky third-party libraries with terrible type definitions.

But let’s be real here – in a brand-new project, you’re probably better off sticking to ES Modules. They’re the standard, they play nice with all the tools, and they generally just make your life easier. But for those legacy codebases, or when you need to wrangle some global constants, namespaces can still be a pretty handy tool to have in your TypeScript toolbox.

Just… maybe don’t go overboard with the nesting, alright? I mean, I’ve seen some things, and they ain’t pretty.

Common questions

Are TypeScript namespaces still useful in 2026 or should I use ES Modules?

For brand-new projects, ES Modules are the better choice because they are the standard, play nicely with all tools, and generally make life easier. However, namespaces still earn a place in the TypeScript toolbox when dealing with legacy codebases or wrangling global constants. They are not the flavor of the month, but they offer tricks ES Modules cannot match.

What can TypeScript namespaces do that ES Modules can’t?

Namespaces support declaration merging, a feature ES Modules simply cannot touch. This becomes surprisingly useful when working with pesky third-party libraries that ship terrible type definitions, since you can augment and extend them cleanly. Namespaces are also essentially just objects, giving you an organized code structure reminiscent of classic patterns like the old $.ajax style of JavaScript development.

Do TypeScript namespaces generate JavaScript code or are they just types?

Unlike pure type constructs, namespaces actually generate real JavaScript code, specifically IIFE-style output. That means they produce runtime artifacts rather than disappearing at compile time. This distinction makes them handy in certain situations where you want organized runtime structure without importing a full module system, and it is part of why they can still serve practical purposes in modern TypeScript.

Can I run TypeScript namespaces in Node.js without a build step?

Yes, and it works smoothly. With Node.js pushing the boundaries on native TypeScript support, namespaces run without any build steps required. The author was pleasantly surprised to find these IIFE-generating relics executing cleanly in that environment. So if you stumble across them in a legacy codebase running on modern Node, you don’t necessarily need to rip them out or add tooling to keep them working.