Build Tools

Vite82.9k★

Vite makes frontend development fast with instant hot module replacement and optimized builds. It serves your source files directly to the browser using native ES modules during development, so there's no bundling step. Change a file, see it in the browser instantly. The feedback loop is faster than anything Webpack gives you. MIT license, created by Evan You (the Vue.js creator). Works with React, Vue, Svelte, Solid, vanilla JS. It's framework-agnostic. Uses esbuild for dependency pre-bundling and Rollup for production builds. The plugin ecosystem covers everything from PWA support to SSR. Fully free. No paid tier, no cloud service. It's a dev tool you install in your project. Vite has essentially won the build tool war for new projects. Create React App is dead. Vue CLI migrated to Vite. SvelteKit uses Vite. Astro uses Vite. If you're starting a frontend project in 2026, you're probably using Vite whether you know it or not. The catch: production builds use Rollup, not the same ESM approach as dev mode, which means occasional behavior differences between dev and prod. Rolldown (Vite's Rust-based replacement for Rollup) is coming but not stable yet. And for very large monorepos, the dev server can get slow. Turbopack in Next.js is specifically targeting that scale.

llvm-project40.5k★

LLVM is the compiler infrastructure that most of the modern toolchain runs on, whether you realize it or not. Clang (C/C++), Flang (Fortran), LLDB (debugger), LLD (linker), libc++, and more, all in one monorepo. Apple, Google, and most major tech companies depend on it. The entire thing is free under Apache 2.0. Self-hosting LLVM is not really the right framing because this is not a service. You build it from source or use your OS package manager. The real question is whether you should use Clang over GCC. For most C/C++ work, Clang gives you better error messages, faster compile times, and tighter integration with modern tooling (LSP, sanitizers, static analysis). GCC still wins in some edge cases around Fortran and certain embedded targets. Solo developers and small teams should just use whatever Clang version ships with their OS. Large teams doing compiler work or building language tooling will want to build from source and target specific LLVM passes. If you are writing a new programming language, LLVM as a backend saves you years of work. The catch: the codebase is massive. Building from source takes serious hardware and time. Contributing requires deep compiler knowledge, and the learning curve is one of the steepest in open source.

esbuild40.1k★

Esbuild does it 10-100x faster than Webpack. Written in Go, compiled to native code, parallelized from the ground up. A bundle that takes Webpack 30 seconds takes esbuild 300 milliseconds. Those aren't marketing numbers. That's what you'll actually see. MIT license, created by Evan Wallace (co-founder of Figma). Handles JS, TypeScript, JSX, CSS, and JSON. Tree-shaking, minification, source maps, code splitting, the core bundling features are all there. Vite uses esbuild internally for dependency pre-bundling. Fully free. It's a CLI tool and Go library. No paid tier, no hosted version. Solo to enterprise: free across the board. The only question is whether you use it directly or through Vite. The catch is what esbuild deliberately doesn't do. No HMR (hot module replacement) for dev servers. No native HTML entry points. Limited plugin API compared to Webpack or Rollup. Evan Wallace has been explicit: esbuild is a bundler, not a framework. If you need a full dev server experience, use Vite (which uses esbuild under the hood). If you need a fast bundler for production builds, CI pipelines, or as a library inside other tools, esbuild is the engine to use.

Just35.9k★

Just runs named commands out of a justfile, so just build means the same thing everywhere, including CI. It is a command runner, not a build system, written in Rust and released into the public domain under CC0. The syntax borrows from Make without the tab sensitivity or implicit rules. Single binary, no daemon, no account, nothing to host. Variables, arguments, conditionals, and per-recipe shell selection (bash, PowerShell, Python) are built in, cross-platform. Version 1.54 added a [cache] attribute that hashes declared input files and skips a recipe when nothing changed, gated behind set unstable. Solo developers get a home for commands living in shell history. Small and medium teams get onboarding: a new hire runs just --list and sees everything the project does. Large teams run it beside the real build system, not instead of it. go-task/task is the closest alternative, YAML instead of a custom format. The catch: the maintainers call cached recipes inherently fragile, and they mean it. The cache key captures declared inputs and little else, so system libraries and network state can shift underneath you while Just skips the recipe anyway. For dependency-driven builds, use Make. Just orchestrates commands, and at that it is excellent.

SWC34.2k★

SWC does the same work as Babel, 20-70x faster, because it's written in Rust instead of JavaScript. It replaces Babel for transpilation and Terser for minification. Apache 2.0, used by Next.js, Deno, and Parcel. When Vercel adopted SWC as Next.js's default compiler, build times dropped dramatically for every Next.js project. That's the real-world validation. Fully free. CLI tool and JavaScript API, no paid tier. The catch: SWC's Babel plugin compatibility is incomplete. If your project relies on specific Babel plugins (especially ones that transform code in unusual ways), you might hit gaps. The bundler (swcpack) is still experimental. Most teams use SWC for transpilation only and pair it with a separate bundler. And when something goes wrong, debugging is harder than Babel because the actual processing happens in Rust, not JavaScript. For most projects the speed gain is worth it, but test your build thoroughly before migrating from Babel.

Turborepo31.1k★

Turborepo makes monorepo builds fast by caching everything and only rebuilding what changed. Instead of running tests and builds for your entire repo on every commit, Turborepo figures out which packages were affected and skips the rest. Fully free under MIT. The CLI, task runner, local caching, and all core features cost nothing. Vercel offers Remote Caching (sharing build cache across your team's machines and CI) through their platform, free on the Hobby plan, included with Vercel Pro/Enterprise. There's nothing to host. It's a CLI tool in your repo. `npx turbo init` in an existing monorepo and you're started. Configuration is a single `turbo.json` file. The learning curve is gentle if you already understand your dependency graph. Solo developers: the local caching alone saves time on rebuilds. Small teams: remote caching is where the magic happens. One person builds, everyone benefits. Large teams: Turborepo or Nx. Those are your two real options. The catch: Turborepo is simpler than Nx but also less powerful. If you need code generation, dependency graph visualization, or affected-project detection beyond builds, Nx does more. Turborepo does less, but what it does, it does with almost zero config.

Nx29.3k★

Nx is the power tool that makes monorepos with multiple apps and libraries manageable. It understands your entire dependency graph (which projects depend on which) and uses that to run only what's affected by your changes. Builds, tests, linting: Nx caches everything and skips what hasn't changed. The core Nx CLI and all open source plugins are free under MIT. Nx Cloud (remote caching and distributed task execution) has a free tier and paid plans starting at $300/mo for Pro. Nx installs as an npm package. No hosting required. It reads your repo structure and generates a project graph automatically. Setup takes 30 minutes for an existing repo. The VS Code extension is useful. It visualizes your dependency graph. Solo developers: Nx is valuable even on smaller repos. The caching saves time immediately. Small teams: the free Nx Cloud tier shares cache across your team. Growing teams: this is where Nx shines. Affected detection and distributed execution cut CI from hours to minutes. The catch: Nx is more complex than Turborepo. More features means more configuration, more concepts to learn, more opinions about how your repo should be structured. If all you need is cached builds, Turborepo is simpler. If you need code generation, project constraints, and module boundaries, Nx is the answer.

Rollup26.3k★

Rollup bundles JavaScript libraries into clean, tree-shakeable output across ESM, CommonJS, and UMD. It was built for library authors who want the smallest possible artifact with dead code stripped out. MIT licensed and free, with no paid tier and no cloud service. Rollup pioneered tree-shaking in JavaScript, walking your import and export graph and removing what nothing references. For library output it still holds up, and its plugin API became the de facto standard that other bundlers now implement for compatibility. Vite used Rollup for production builds for years; Vite 8 replaced it with rolldown/rolldown, a Rust rewrite that keeps the Rollup plugin API. That is a real shift in where Rollup sits in the ecosystem. Free at every size, because it is a CLI and a JavaScript API and nothing else. Solo maintainers, small teams, and large orgs run the identical tool. The plugin ecosystem is mature, and much of it now runs on Rolldown too, so learning Rollup's plugin model is not wasted effort either way. The catch is scope and speed. Rollup is for libraries, not applications; building a web app means reaching for Vite. And Rollup is JavaScript, so esbuild, SWC, and Rolldown are all substantially faster. If your library builds take seconds, stay put. If they take minutes, Rolldown is the shortest move because your existing plugins and config mostly carry over.

OXC22.8k★

OXC wants to replace your JavaScript parser, linter, formatter, and minifier, and do all of it 10-100x faster. It's a collection of JS tooling rewritten in Rust with performance as the obsession. The linter alone runs ~50-100x faster than ESLint on real codebases. Everything is free under MIT. No paid tier, no cloud service, no enterprise upsell. This is pure open source tooling backed by VoidZero (the company behind Vite). There's nothing to self-host: it's developer tooling you install as a dependency. `npm install oxlint` and you're running. Zero configuration works out of the box, though you can customize rules. The parser is used internally by other tools (Rspack, Rolldown) so you're probably already benefiting from it indirectly. Solo developers: switch your linter to oxlint today. The speed difference is immediately noticeable. Small to large teams: the CI time savings alone justify the switch: minutes off every pipeline run. The formatter is newer and less battle-tested than Prettier, but the linter is solid. The catch: OXC isn't ESLint-compatible. You can't use your existing ESLint plugins. The oxlint rules cover most common cases but the plugin ecosystem is nowhere close. If you rely on niche ESLint plugins, you'll run both for a while.

Task16.2k★

A modern replacement for Make. If you have a project with build commands, test scripts, deploy steps, or any repeatable tasks and you're tired of writing Makefiles with their tab-sensitivity and cryptic syntax, Task uses a simple YAML file instead. Define your tasks in a `Taskfile.yml`, run them with `task build`, `task test`, `task deploy`. It handles dependencies between tasks, runs things in parallel, watches files for changes, and works on Linux, Mac, and Windows without any compatibility headaches. Written in Go, ships as a single binary with zero dependencies. Completely free. MIT licensed. No paid tier. Install via brew, go install, npm, or download the binary. The catch: it's "just" a task runner. If you need a full build system with caching, remote execution, and dependency graph optimization, look at Turborepo, Bazel, or Nx. Task doesn't cache outputs; it re-runs every time unless you set up fingerprinting manually. For most projects, that doesn't matter. But for large monorepos with 30-minute builds, you need something smarter. For everything else, Task is cleaner than Make and simpler than everything else.

GoReleaser16.1k★

One command, and your release ships everywhere. MIT license, Go. Builds for Linux, macOS, Windows, ARM, AMD64 in parallel. Creates GitHub/GitLab releases with changelogs, publishes to Homebrew taps, Docker registries, Snapcraft, Scoop, and APT/RPM repositories. Integrates with CI (GitHub Actions, GitLab CI) for fully automated releases. Free tier (GoReleaser OSS): handles most release workflows: cross-compilation, GitHub releases, Docker images, Homebrew. Covers 90% of use cases. Pro: $11/month (billed annually at $132/year). Adds: custom publishers, monorepo support, Nix packages, and priority support. Enterprise: custom pricing for larger organizations. Solo Go developers: the free version is everything you need. Small teams: free unless you're in a monorepo. Medium teams: $11/mo Pro when you need custom publishers or monorepo support. The catch: it's Go-specific. If you release in multiple languages, you need separate release tooling for each. And the config file (`.goreleaser.yaml`) gets complex fast when you're targeting many platforms with different build flags. The docs are good but the config surface area is large.

rolldown13.9k★

Rolldown bundles your JavaScript and TypeScript, taking all your source files and packing them into optimized output for the browser, the same job Webpack and Rollup do. The difference is it's written in Rust, so it's fast, and it keeps Rollup's API and plugin interface so most existing setups port over without a rewrite. MIT licensed and free. There's nothing to host or operate. It installs as a dependency and runs in your build step locally and in CI. If you've used Rollup, the config will feel familiar; the scope leans closer to esbuild, meaning it does more out of the box. The real context here is Vite. Rolldown is being built to become Vite's bundler under the hood, which is why it matters even if you never call it directly. Solo, small, or large teams: same free tool, no ceiling. If you want the most battle-tested option today, Rollup and esbuild are still the safe picks. The catch: it's young and still stabilizing. Plugin compatibility is good but not total, and edge cases will bite on complex builds. Great to try on a new app, riskier to rip Webpack out of something large and critical right now.

rspack12.9k★

Rspack does webpack's job in Rust. A bundler takes the hundreds of JavaScript files in your project and packs them into a handful the browser can load, and webpack has been the default for a decade. Rspack keeps webpack's config format and most of its plugin and loader ecosystem, so migration is often a config rename rather than a rewrite. MIT licensed, nothing gated. The pitch is rebuild time. Rust plus incremental compilation keeps hot module replacement fast on large codebases, which is exactly where webpack starts to hurt. It comes from ByteDance's web infra team and anchors a wider toolchain: Rsbuild wraps it with defaults, Rspress builds docs sites. You install it from npm, so there is no ops burden. Use it when you have a big webpack config you do not want to rewrite. Starting fresh, Vite is the more common default and Turbopack is Vercel's answer to the same problem. Compatibility is the reason to pick Rspack, not novelty. The catch is that webpack compatibility is high, not total. Plugins that reach into webpack internals instead of its public hooks break, and Module Federation is where people usually get stuck. Check your plugin list before promising anyone a one day migration.

scriptc4.9k★

scriptc compiles TypeScript straight to a native binary, with no Node or V8 along for the ride. It runs your source through the real tsc type checker, lowers it to a typed intermediate representation, emits C, and lets clang produce a small native executable, around 200KB, that starts cold with none of a JS engine's overhead. It's a genuine Vercel Labs project, confirmed by its Hacker News debut and press coverage, not a name-squat. The numbers are the hook: in Vercel's own demo, startup drops from roughly 47ms on Node to about 2.4ms, in a static binary a fraction of the size. For CLIs and small tools, that's a meaningful difference. Free under Apache 2.0, install it from npm, bring clang. The catch is that it's very early, v0.0.x with no stable release. macOS arm64 is the primary target, with Linux and Windows via cross-compile, and realistically only a subset of TypeScript compiles today. It competes with Bun and Deno's compile commands, Node's single executable apps, and honestly with just reaching for Go or Rust on a small CLI. Fascinating and worth watching, but this is an experiment to play with, not a build step to depend on yet.

shadow4.2k★

Shadow is how the JVM world ships a single runnable jar. It's the Gradle plugin for building fat/uber JARs: your code plus every dependency in one file, with package relocation to prevent version conflicts and optional R8/ProGuard shrinking. It's the Gradle counterpart to Maven's Shade plugin, free and open source. Nothing to run; it's a build plugin. The one operational thing to know is the identity change: the plugin moved from the old com.github.johnrengelman.shadow coordinates to the GradleUp organization, so new builds should use com.gradleup.shadow to keep receiving fixes. Anyone distributing JVM CLIs, Spark jobs, or plugins needs this or something like it. Relocation is the feature that separates it from a naive merged jar: two libraries demanding different Guava versions stops being your problem. The catch: fat jars are a distribution choice with costs. Merged service files and duplicate resources need configuring, builds get slower, and Spring Boot apps don't need it because Boot's own packaging already does this job.

weapp-tailwindcss1.9k★

weapp-tailwindcss makes Tailwind CSS work inside WeChat mini-programs, which normally choke on Tailwind's class names because their CSS engines reject the special characters and selectors Tailwind generates. The plugin rewrites those class names into something mini-programs accept, converts values into rpx (the unit mini-programs use for sizing), and lets the same styling code ship to WeChat, Alipay, and Douyin mini-programs plus regular web. MIT-licensed, free, on npm. There's no service to run. It's a build-step plugin that hooks into Vite, Webpack 5, or Rspack and works with the uni-app, Taro, and Mpx frameworks. It supports Tailwind v3 and v4 and ships a stack of companion packages for class merging, variants, and mini-program UI components, so it's more an ecosystem than a single shim. Solo: if you're building a mini-program and want Tailwind, this is the standard way to do it. Small teams: same, it removes a whole category of styling friction. Large teams shipping cross-platform mini-programs: this is close to mandatory if you've standardized on Tailwind. The catch: the audience is narrow. Outside the Chinese mini-program ecosystem this solves a problem you'll never have, and the documentation leans Chinese-first, so non-Chinese-reading teams will spend extra time in translation. If you're not shipping to WeChat or its cousins, skip it.

open-watcom-v21.3k★

Open Watcom V2 keeps the classic Watcom C, C++, and Fortran compiler alive and building. It's a full toolchain (compilers, linkers, assemblers, and a debugger) that still targets DOS, Windows, OS/2, and Linux from a single install. Open source under the Sybase Open Watcom license, free, and actively maintained by a community after the original openwatcom.org went dormant. The reason anyone reaches for this in 2026 is target support nothing modern offers. If you're building for 16-bit DOS, OS/2, or other retro and embedded targets, Open Watcom compiles for them out of the box where GCC and Clang would need heavy coaxing or simply can't. Retro game developers, legacy industrial systems, and hobbyist OS projects are the core audience. Setup is a straightforward installer or build-from-source on a modern machine. For mainstream C and C++ work, this isn't your compiler. GCC, Clang, and MSVC are faster, produce better code, and own the ecosystem. Open Watcom earns its place when the target matters more than raw optimization: shipping a DOS executable, maintaining an OS/2 application, or learning how compilers worked before LLVM. Free for everyone, hobbyist or commercial. The catch: it's a preservation and niche-target project, not a competitor for modern development. Optimization and C++ standards support lag well behind the mainstream compilers, and the community is small. Use it because you need what only it can target, not because you expect cutting-edge codegen.