Imports

Now, let’s talk about getting lazy. And I mean that in the best possible way. Why should your user’s browser have to download, parse, and compile every single module your application might need the moment the page loads? It shouldn’t. That’s a great way to make your app feel like it’s running on a potato connected by two cans and a string. Enter import(). This isn’t the static import statement you put at the top of your file. This is a function—a function that returns a promise. And it is the single most powerful tool you have for lazy-loading modules. It lets you say, “Hey, I might need this chunk of code later, but only fetch it and get it ready when I actually ask for it.” This is the cornerstone of code-splitting, and it will make your performance metrics sing.

Right, so we need to talk about TypeScript namespaces. I know, I know. You’re probably thinking, “Wait, didn’t we just cover modern ES modules? Why are we going backwards?” Because, my friend, the real world is a messy place filled with legacy code, and you will encounter these. They are TypeScript’s original, pre-ES6 module system, a pattern we now call “namespace modules.” Think of them as a verbose, clunky precursor to import/export that lives entirely in the global scope. They’re like that old, heavy piece of furniture in your codebase that’s too much of a hassle to move, so you just keep building around it.

Alright, let’s talk about grabbing the whole candy bowl instead of just one piece. The import * as ns syntax is your “I’ll take it all, thanks” move. It creates a single namespace object that contains all the exports from a module. It feels powerful, like you’re getting a great deal, but I need to be your brilliant friend here and tell you to use this power sparingly. It’s the culinary truffle of imports—potent, but a little goes a long way and it can ruin the dish if you’re not careful.

Alright, let’s talk about two of the most misunderstood entries in your tsconfig.json: esModuleInterop and allowSyntheticDefaultImports. If you’ve ever been greeted by the infamous error Module '"...module-name..."' has no default export, you’ve stumbled into the exact problem these options are designed to solve. They exist to paper over a fundamental crack in the JavaScript ecosystem: the Great Module Schism between CommonJS (CJS) and ES Modules (ESM). The core of the issue is that CJS modules require and export things differently than ESM modules import and export them. A CJS module can always do module.exports = someFunction, resulting in a single “default” export. In the ESM world, that’s written as export default someFunction. But what if you import a CJS module that exports a single function into an ESM file? What do you get?

Right, let’s talk about the awkward handshake between the two worlds. You’re in ES Module land, living your best life with import and export, but then you look over the fence and there’s a giant pile of legacy code written in CommonJS (require and module.exports). You can’t just ignore it. Node.js had to figure out a way to make these two talk to each other without everything exploding, and they called it “interop.” It’s mostly graceful, except for the parts where it’s absolutely not.

Right, let’s talk about import type. This is one of those features that feels like a bureaucratic formality until the moment it saves you from a truly spectacular runtime error. It exists for one simple, beautiful reason: to help TypeScript do its job without getting its hands dirty with JavaScript’s messy runtime business. Here’s the core idea: a normal import statement does two things. It tells TypeScript “I need this type for my type-checking,” and it tells your JavaScript bundler or runtime “I need this code to be included and executed.” Most of the time, this is exactly what you want. But sometimes, you only care about the type information. You don’t want any JavaScript code generated for that import. This is where import type comes in. It’s a firm, clear instruction to the TypeScript compiler: “Hey, just get the type info from this file and then leave it alone. Don’t emit any require statements for it.”

Now, let’s talk about one of my favorite organizational tricks: re-exporting. It’s the module system’s version of a helpful friend who introduces you to everyone at a party without you having to run around collecting names yourself. At its core, re-exporting lets you grab exports from one module and sell them as your own from another. The primary use case for this is the barrel file, a single file that rolls up and re-exports a bunch of other exports. This creates a clean, centralized public API for a directory or package.

Right, let’s talk about ES Modules. This is the official, standardized way to handle modules in JavaScript, and frankly, it’s about time. If you’ve been wrestling with require and module.exports in CommonJS (and we’ll get to that mess shortly), this is the clean, logical, and frankly superior system you’ve been waiting for. The syntax is purposefully designed to be statically analyzable, which is a fancy way of saying tools (and your brain) can figure out what’s going on before the code runs. This unlocks all sorts of goodies like better bundling, dead code elimination, and reliable tree-shaking.