Tired of TypeScript builds failing because of environment-specific code? Discover how an AST-based context compiler can surgically remove code at build time, eliminating runtime checks and dependency headaches for good.

That Time a Mock API Took Down Production

I still get a cold sweat thinking about it. It was 2 AM, a Tuesday. We were pushing a hotfix for the payments service. The PR looked clean, the tests passed on staging, everything was green. We hit merge. Ten minutes later, PagerDuty started screaming. Every single transaction on `prod-payments-api-01` was failing with a cryptic “User Mockington not found” error. It turns out a junior dev, trying to be helpful, had left a small snippet of test code wrapped in a `if (process.env.NODE_ENV !== ‘production’)` block. The problem? The mock data library it imported was a dev-only dependency. The production build process dutifully pruned it from `node_modules`, but the `import` statement was still at the top of the file. The bundler saw the import, freaked out, and the whole module failed to load. The `if` statement never even got a chance to run. We spent the next hour rolling back and trying to figure out how our CI/CD pipeline let that slip through. That night, I learned a hard lesson: runtime environment checks are a landmine waiting to be stepped on.

The “Why”: Build-Time Truth vs. Runtime Hopes

So, what’s really going on here? We all write code like this, thinking we’re being safe:

import { getMockUserData } from './testing/mocks';

function getUser(userId) {
  if (process.env.NODE_ENV === 'development') {
    // We only run this on our local machines, right?
    return getMockUserData(userId);
  }
  // ... production database logic here
}

The problem is that by the time your code is running on a server, your bundler (like Webpack or Vite) has already made its decisions. It sees `import { getMockUserData } …` at the top and says, “Okay, I need this file and its dependencies.” It doesn’t care that you only *plan* to use it inside a conditional block. If that dependency isn’t there in your `package.json`’s `dependencies` (because it’s in `devDependencies`), your build fails. Or worse, it builds but fails at runtime. Your `if` statement is a runtime suggestion, but the `import` is a build-time command.

The Fixes: From Duct Tape to a Welded Frame

Let’s walk through how we can solve this, from the quick-and-dirty fix to the way we do it now at TechResolve for our critical systems.

1. The Quick Fix: Dynamic Imports

This is the “get me out of this mess right now” solution. Instead of a static import at the top of the file, you use a dynamic `import()`. This tells the bundler to treat the module as a separate, async chunk.

async function getUser(userId) {
  if (process.env.NODE_ENV === 'development') {
    const { getMockUserData } = await import('./testing/mocks');
    return getMockUserData(userId);
  }
  // ... production database logic here
}

Why it works: The bundler sees the dynamic import and knows not to fail if the module isn’t immediately available. The code path is never hit in production, so the `import()` is never called, and the missing module is never an issue.

Why it’s “hacky”: You’re introducing asynchronicity (`async/await`) where it might not be needed, which can complicate your function’s signature. You’re also still shipping the *logic* for the check to production, even if the code itself isn’t called. It’s dead code, and dead code can sometimes come back to haunt you.

2. The Permanent Fix: Build-Time Definitions

A much cleaner approach is to tell your build tool about your environments. Most modern bundlers have a way to define global constants that will be replaced *before* the code is even parsed for dependencies. Here’s how you might do it in Vite (`vite.config.ts`):

// vite.config.ts
export default defineConfig({
  define: {
    '__IS_DEV__': process.env.NODE_ENV === 'development',
  },
});

Now, in your application code, you use this new global:

import { getMockUserData } from './testing/mocks';

function getUser(userId) {
  if (__IS_DEV__) {
    return getMockUserData(userId);
  }
  // ... production database logic here
}

When you run your production build, the bundler literally replaces `__IS_DEV__` with `false`. The code becomes `if (false) { … }`. Modern tools are smart enough to see this and eliminate the entire block as unreachable “dead code”. This process, called tree-shaking, will also remove the now-unused `import { getMockUserData }…`. Problem solved. The mock code never even makes it into your final bundle.

Pro Tip: Don’t use `process.env` directly in your frontend code for this. It’s better to abstract it behind build-time flags like `__IS_DEV__` or `import.meta.env.VITE_SOME_KEY`. This makes your code’s dependency on the environment explicit and easier for the bundler to analyze.

3. The ‘Nuclear’ Option: AST-based Context Compilation

Okay, now for the really cool stuff. What if your logic is more complex than just a dev/prod split? What if you have logic for different customers, feature flags, or even different platforms (e.g., web vs. desktop)? This is where simple variable replacement starts to get messy. You end up with a dozen `if (__IS_CUSTOMER_A__)` checks all over your codebase.

This is the problem tools like LogicStamp (and the concept in general) are built to solve. They don’t just replace variables; they parse your code into an Abstract Syntax Tree (AST) – a tree-like representation of your code’s structure. Then, based on a context file you provide, they can surgically add, remove, or modify entire branches of that tree before the final code is ever generated.

Imagine you have a configuration file:

// build-context.json
{
  "target": "web",
  "featureFlags": {
    "useNewAnalytics": true
  }
}

An AST-based compiler could take your source code and transform it based on that context. It’s not just about removing dead code; it’s about generating the *perfect* code for a specific context.

// @ls-check-flag useNewAnalytics
import { newAnalytics } from './analytics-v2';
// @ls-check-flag !useNewAnalytics
import { oldAnalytics } from './analytics-v1';

export function trackEvent() {
  // @ls-if useNewAnalytics
  newAnalytics.track();
  // @ls-else
  oldAnalytics.log();
  // @ls-endif
}

import { newAnalytics } from './analytics-v2';

export function trackEvent() {
  newAnalytics.track();
}

Look at that result. It’s not just that the `else` block is gone; the `import` for `oldAnalytics` is gone too. There’s zero runtime overhead, zero dead code, and zero chance of the `analytics-v1` module causing issues in a build where it’s not needed. This is the ultimate form of build-time configuration. It’s powerful, clean, and for complex, multi-tenant, or multi-platform applications, it’s a lifesaver. It turns your build pipeline into an intelligent code generator, not just a simple bundler.

So next time you find yourself writing `if (process.env.NODE_ENV === ‘…’)`, stop and think. Are you just hoping for the best at runtime, or are you telling your build process exactly what you need? Trust me, your PagerDuty will thank you for choosing the latter.

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