Simplifying the TS Toolchain: Running TypeScript Without a Build Step

The Build Step Fatigue

For years, the standard TypeScript workflow has been a multi-stage process: write code, run a compiler (tsc) to transpile it to JavaScript, manage a tsconfig.json, and then execute the result in a runtime like Node.js. This creates a "compile-wait-run" loop that slows down development and adds layers of configuration that often drift between local and production environments.

The core problem is that TypeScript is a development-time tool, while the runtime is a separate entity. Deno solves this by integrating the TypeScript compiler directly into the runtime, effectively treating TypeScript as a first-class citizen. The takeaway is simple: you can execute .ts files directly, eliminating the need for a separate build pipeline for many applications.

Native Execution and the Security Sandbox

When you run a script in Deno, the runtime handles the type-checking and transpilation in the background. However, this convenience comes with a strict security model. Unlike traditional runtimes that have full access to your hard drive and network, Deno is secure by default. It operates in a sandbox, meaning it cannot access the disk, network, or environment variables unless you explicitly grant permission via command-line flags.

This shift moves security from a configuration file to the execution command, making it clear exactly what permissions a script requires to function.

Managing Dependencies Without node_modules

Deno replaces the centralized node_modules folder with URL-based imports. Instead of installing a package globally or locally via a package manager, you import the module directly from a URL. Deno caches these modules locally the first time they are run, ensuring that subsequent executions are fast and do not require a network connection.

To maintain consistency across environments, Deno uses a lock file to ensure that the remote code hasn't changed between deployments, providing the same stability as a package-lock.json without the disk-space overhead of thousands of small files.

Example: Building a Secure HTTP Server

The following example demonstrates how to use the Deno Standard Library (std) to create a basic server. This requires no npm install and no tsc command.

// server.ts
import { serve } from "https://deno.land/std@0.190.0/http/server.ts";

const port = 8080;
const handler = async (request: Request): Promise<Response> => {
  return new Response("Hello from Deno native TS!");
};

console.log(`Server running on http://localhost:${port}`);
await serve(handler, { port });

Execution and Verification

To run this file, execute the following command in your terminal. You must run this as a user with permissions to bind to the specified port:

deno run --allow-net server.ts

Expected Check: If you omit the --allow-net flag, Deno will throw a PermissionDenied error and prompt you to provide the flag. This confirms the sandbox is active. Once the flag is added, visiting http://localhost:8080 should return the response text.

Trade-offs and Limitations

While removing the build step is a massive productivity boost, it introduces specific challenges:

• Remote Dependency Risk: Relying on URLs means your app could fail if a remote host goes down. To mitigate this, use a deno.json import map to alias URLs to local versions or a private registry.
• Legacy Compatibility: Deno uses ES Modules. If you need to use an older CommonJS package from the npm ecosystem, you must use the npm: specifier (e.g., import lodash from "npm:lodash"), which adds a layer of compatibility mapping.
• CI/CD Friction: In automated pipelines, you must explicitly map every required permission flag. Forgetting --allow-env in a production pipeline can lead to runtime crashes when the app tries to read an API key.

Actionable Next Step

To test this workflow on an existing project, try replacing your tsc and node execution chain with deno run. Start by running deno lint and deno fmt on your source files to see how the integrated tooling handles your current TypeScript style without needing a .prettierrc or .eslintrc file.