# Farm: a Rust bundler that runs Vite plugins and ships with production parity

> Farm is a Rust-based web build tool that compiles JS/TS/JSX/TSX, CSS, CSS Modules, HTML and static assets, accepts Vite plugins since v0.13, and claims the same pipeline in development and production. Here is what the repository actually documents, and where the edges are.

**farm-fe/farm** — Extremely fast Vite-compatible web build tool written in Rust

- Repository: https://github.com/farm-fe/farm
- Website: https://farmfe.org
- Stars: 5,593 · Forks: 190
- Language: Rust
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/farm-fe-farm

## What Farm is trying to fix about the Vite development model

The README's "Why Farm" section makes a specific argument rather than a general speed claim. It names three problems with the Vite approach on large projects: a huge number of requests during development, inconsistency between development and production, and inflexible code splitting. The request-count complaint is the concrete one. An unbundled dev server serves each module as a separate request, so a page with hundreds or thousands of modules pays that cost on every refresh. Farm's answer is to bundle during development too, which is why its dev and production pipelines can share a strategy instead of diverging.

The audience is therefore not everyone. A small React or Vue app with a few dozen modules will not notice the difference, because the request waterfall never becomes the bottleneck. The target is a project where the module graph is large enough that refresh latency is a real cost, and where the team has been bitten by a production-only bug that could not be reproduced in dev. Farm's stated goal of consistency is aimed squarely at that second pain.

## The Rust compiler, the plugin layers, and partial bundling

The repository layout shows the architecture directly. crates/ holds the Rust workspace members, rust-plugins/ and rust-ecosystem/ hold Rust-side plugin crates, js-plugins/ holds JavaScript plugins, and packages/ holds the npm packages including @farmfe/core and @farmfe/cli. The Cargo.toml workspace depends heavily on swc crates for parsing, transforming, minifying and code generation across JavaScript, TypeScript, CSS and HTML. That is the compiler core: Farm is not writing its own parser, it is orchestrating SWC and adding its own module graph, cache and bundling layer on top.

The plugin model has several distinct layers, and the README lists them: Farm compilation plugins in both Rust and JavaScript, SWC plugins, Farm runtime plugins, and Farm server plugins. That is a wider surface than a single plugin interface, and it is the reason Vite plugin compatibility is possible at all. Since v0.13, per the README note, Vite plugins can be used directly in Farm. A Vite plugin written in JavaScript runs in the JavaScript plugin layer; a performance-sensitive transform can instead be written in Rust.

Partial Bundling is the piece that differs most from both webpack and Vite. The README points to RFC-003 for the full design and describes the behavior as bundling the project into a few reasonable bundles automatically, to speed up resource loading without losing caching granularity. In practice that means the tool decides the chunk split rather than leaving it entirely to manual configuration. The trade-off is real: automatic splitting is convenient until you need a specific chunk boundary for a specific deployment constraint, and the README does not describe an escape hatch for that case.

## Installing Farm and running a first build

The README gives the scaffold command for three package managers. The repository's package.json declares engines.node >= 20, so check your Node version before you start.

```bash
npm create farm@latest
```

The same command exists as yarn create farm@latest and pnpm create farm@latest. Running it prompts for a project name and a template, then writes a project directory with a farm.config.ts and the dependencies already wired. The recent releases list shows create-farm@2.0.0-beta.4 published on 2026-05-28, so the scaffolder has a beta line in addition to the stable one.

After the scaffold, the generated package.json carries the usual scripts. The repository root's own scripts show the naming convention the project uses internally, with build:core filtering to @farmfe/core and build:cli filtering to @farmfe/cli, so a scaffolded app follows the same shape.

```bash
cd my-farm-app
npm install
npm run dev
```

The dev server starts and prints a local URL. Because Farm bundles in development, the first start compiles the module graph rather than serving files on demand, which is the opposite of the Vite experience: the first request is slower, and subsequent HMR updates are fast. The README claims an HMR update within 20ms for most situations; treat that as the project's own figure, not a measurement you can rely on for your codebase.

Since v0.14, persistent disk cache is enabled by default. That means the second start reuses compiled modules from disk, and only changed modules are recompiled. If you see stale output after changing a dependency, that cache is the first thing to inspect.

## Where the Vite compatibility claim stops

Vite plugin support is the headline compatibility feature, and it is also the one most likely to disappoint in a specific way. The README says Vite plugins can be used directly in Farm since v0.13 and links to a documentation page on using plugins. It does not enumerate which plugin hooks are supported, which are ignored, and which throw. A Vite plugin that only transforms module source has a good chance of working. A plugin that reaches into the dev server's middleware stack, its WebSocket protocol, or its internal module graph is operating against an implementation Farm does not share, and the README offers no compatibility matrix to tell you which is which.

The practical consequence is that "Vite-compatible" is a claim about the plugin API surface, not a guarantee that an arbitrary Vite project migrates unchanged. If your build depends on a plugin that hooks the dev server, budget time to verify it rather than assuming it. The repository does provide an examples/ directory with a large number of named cases, including css-modules, css-url, decorators, env, external, hmr, import-meta, lazy-compilation, less and multi-page-app, which is where to look for a working configuration close to yours before filing anything.

A second limitation is ecosystem depth. Vite has years of third-party plugins, framework integrations and community answers. Farm's own plugin layers are documented, but the number of plugins written specifically for Farm is smaller, and the README does not claim otherwise.

## Farm against Vite and webpack: what actually differs

The README's benchmark section states Farm is 20x faster than webpack and 10x faster than Vite, and links to a separate repository, farm-fe/performance-compare, for the methodology. That is the project's own benchmark on its own hardware and workload. It is a directional signal about the compiler being native code, not a number that transfers to your project.

The architectural difference from Vite is where the work happens. Vite in development serves native ES modules and lets the browser resolve imports, which is why startup is nearly instant and why a page with a large module graph issues a large number of requests. Farm compiles and bundles in development, so startup costs more and per-page load costs less. If your project is small, Vite's model wins on startup and you will not see the benefit Farm is selling.

The difference from webpack is narrower than it first appears. Both bundle in development. Farm's distinction is that the compiler is Rust with SWC underneath rather than JavaScript, and that Partial Bundling makes chunk splitting automatic. webpack gives you explicit control over splitting through configuration; Farm gives you an automatic strategy. If your build depends on hand-tuned splitChunks behavior, that control is the thing you would be giving up, and the README does not describe a direct equivalent.

## Licence, maintenance and the cost of tracking a fast-moving tool

Farm is MIT licensed. The Cargo.toml workspace sets license = "MIT" for the workspace package, and the repository root carries a LICENSE file. MIT is permissive: you can use it commercially, modify it, and redistribute it, provided the copyright notice and licence text travel with the code. That is the general shape of the licence, not advice about your situation; if you vendor or fork the compiler, read the LICENSE file and the licences of the SWC crates it depends on, since those are separate works with their own terms.

The upgrade cost is the part worth thinking about before committing. The recent releases shown are all 2.0.0-beta versions of create-farm, create-farm-plugin and @farmfe/plugin-yaml, published on 2026-05-28. A beta line running alongside a stable 1.x means the project is actively changing its plugin and scaffolding interfaces. The README also notes two behavior changes that arrived in minor versions and changed defaults: Vite plugin support in v0.13 and persistent disk cache enabled by default in v0.14. Defaults that change under you are the expensive kind of upgrade, because they alter build output without a config diff.

The last push to the repository was on 2026-09-22, so the project is being worked on. That says nothing about whether your specific issue will be fixed, and the README does not document a support policy or a release cadence commitment.

## Conclusion

Farm fits teams with large module graphs who feel the request waterfall of an unbundled dev server, and teams already invested in Vite plugins that want a Rust compiler without rewriting them. It is the wrong choice if you depend on a Vite plugin that hooks into dev-server internals beyond the documented compatibility surface, or if you need a mature plugin ecosystem with years of third-party coverage. Before adopting, verify three things on your own codebase: that your Vite plugins load under Farm, that the persistent cache in .farm does not mask stale modules after a dependency upgrade, and that your Node version is at least 20, since the repository's package.json declares engines.node >= 20.

## FAQ

### What is Farm fe farm?

Farm is a web build tool written in Rust, described in its README as Vite-compatible, that compiles JS, TS, JSX, TSX, CSS, CSS Modules, HTML and static assets out of the box. It is published on npm as @farmfe/core, and the README states it reached 1.0 stable and production ready.

### How do I install Farm?

The README gives npm create farm@latest, with yarn create farm@latest and pnpm create farm@latest as equivalents. The repository's package.json declares engines.node >= 20, so a current Node release is required.

### Can Farm use Vite plugins?

Yes, since Farm v0.13, according to a note in the README, which links to a documentation page on using Vite plugins in Farm. The README does not list which plugin hooks are supported, so compatibility has to be checked per plugin.

### Is Farm faster than Vite and webpack?

The README states Farm is 20x faster than webpack and 10x faster than Vite, and links to the farm-fe/performance-compare repository for the benchmark. Those figures come from the project's own benchmark, not from an independent measurement.

### Does Farm cache compiled modules on disk?

Since Farm v0.14, persistent disk cache is enabled by default, per a README note that links to the incremental building documentation. The README describes it as module level cache, so a module is not compiled twice until it changes.

## Sources

- [farm-fe/farm on GitHub](https://github.com/farm-fe/farm)
- [License: MIT](https://github.com/farm-fe/farm/blob/main/LICENSE)
- [Project website](https://farmfe.org)
- [README](https://github.com/farm-fe/farm/blob/main/README.md)
- [Releases](https://github.com/farm-fe/farm/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/farm-fe-farm