Turf.js: a modular geospatial engine for JavaScript and TypeScript

What Turf.js solves, and who it is for

Turf is a JavaScript library for spatial analysis. The README describes three groups of functions: traditional spatial operations, helper functions for creating GeoJSON data, and data classification and statistics tools. That combination is the point. If you have a browser map, a Node service, or a build step that already speaks GeoJSON, Turf lets you compute on those geometries in the same runtime instead of shipping coordinates to a spatial database and waiting for an answer.

The audience is narrower than "anyone doing GIS". It is developers who write JavaScript or TypeScript and whose geometry work is per-feature: measuring a line, buffering a point, testing whether a coordinate falls inside a polygon, intersecting two shapes, classifying values, producing summary statistics. The README states that Turf can be added to a website as a client-side module or run server-side with Node.js. Those are the two deployment shapes the project supports, and they cover most of the reasons people reach for it.

Modular packages, and what that means for your bundle

The repository is a monorepo. The top level holds packages/, a pnpm-workspace.yaml, a pnpm-lock.yaml, a shared tsconfig.shared.json, and a root package.json whose build script is `pnpm --filter @turf/turf build`. The published entry point named in the README is the npm package @turf/turf, and the repository also carries examples/ directories for browser, create-react-app, es-modules, and es-modules-single-module use.

That layout explains the project's own description of itself as modular. The single-module example directory is the tell: instead of importing everything, you can depend on one operation. The trade-off is real. A modular package graph means many small dependencies, and the README is explicit that when bundling Turf for the browser you must ensure your build setup transpiles and polyfills Turf along with all of its transitive dependencies to match your target browsers. That is a build configuration obligation, not a footnote. Teams that assume a modern bundler handles it by default can end up with a bundle that fails on older targets.

Runtime support is stated plainly. Node is a first class citizen, and the README recommends an Active or Maintenance LTS release. Deno and Bun are not officially supported; the project says it would be interested to hear about experiences with them. Read that as: they may work, but you are outside the tested path.

Installing Turf.js and running a first operation

The README points to the getting started guide at turfjs.org/docs/getting-started and to the API examples at turfjs.org. For a Node project, the published package is @turf/turf. The exact version to pin is whatever your registry resolves; the recent releases listed in the repository are v7.4.0, v7.3.5, and v7.3.4.

Install it from npm:

npm install @turf/turf

Turf consumes and returns GeoJSON, so the input is a Feature or FeatureCollection rather than a custom object type. The README does not print a worked example of a call, so the shape of the result is the thing to check in your own code: a geometry operation returns a GeoJSON Feature, not a bare array of coordinates. The repository's examples/ directory, which includes browser, create-react-app, es-modules, and es-modules-single-module entries, is where the project keeps runnable starting points for the two deployment shapes it supports.

If you are targeting the browser, the README states that @turf/turf includes a browser bundle that combines, transpiles, and minifies all Turf modules into a single JavaScript file. That bundle is the alternative to wiring individual modules through your own build.

Where Turf stops being the right tool

Turf is a library, not a spatial database. Nothing in the README describes an index, a persistent store, or a query planner. If your problem is "find the nearest of two million points" or "join these two large layers by geometry", the per-feature function model works against you: you would be looping in JavaScript over data that a database with a spatial index is built to handle. Turf is the wrong tool for that shape of workload, and the README does not claim otherwise.

The second limitation is environmental. Deno and Bun are explicitly not officially supported. If your stack is built on either, you are running untested. The README invites feedback rather than offering a compatibility guarantee.

The third is the bundling constraint already noted: browser builds require your setup to transpile and polyfill Turf and its transitive dependencies. The README does not document a fallback if your target browsers fall outside the Browserslist default preset that the project periodically updates its minimum targets against. There is also no rollback or migration guidance in the README for moving between major versions, so upgrading across a major release means reading the CHANGELOG.md and releases/ directory in the repository rather than relying on a documented procedure.

Turf.js compared with PostGIS

The obvious alternative for server-side spatial work is PostGIS, and the difference is architectural rather than a matter of feature checklists. PostGIS puts geometry types and spatial functions inside PostgreSQL, so the data stays in the database and operations run where the index lives. Turf puts the operations in your JavaScript runtime and the data in memory as GeoJSON.

That changes what each is good at. With PostGIS you write SQL, and the database can use a spatial index to avoid scanning every row. With Turf you write function calls on GeoJSON objects you already hold, which means no network round trip and no database to run, but also no index and no query planner. A browser map that needs to buffer a drawn shape or measure a route has no database to call, and Turf fits there. A backend that needs to answer spatial queries over a growing table is a PostGIS problem.

The two are not mutually exclusive, and the README does not frame Turf as a PostGIS replacement. It frames it as a JavaScript library for spatial analysis with a client-side and a server-side mode. Choose based on where your data lives and how large it is.

Licence, releases, and upgrade cost

Turf is MIT licensed. The repository carries a LICENSE file at the top level. MIT is permissive: it allows use, modification, and redistribution provided the copyright notice and permission notice are preserved. That is a description of the licence text, not legal advice, and if you redistribute Turf inside a product you should read the LICENSE file yourself rather than take this paragraph as a substitute.

Upgrade cost is tied to the release cadence. The listed releases are v7.4.0 on 2026-08-03, v7.3.5 on 2026-04-20, and v7.3.4 on 2026-02-08. The last push to the repository was on 2026-09-07. Patch releases at that spacing suggest maintenance rather than a project in the middle of a rewrite, and the repository is not archived.

The practical upgrade cost comes from the monorepo structure. Because Turf is published as many small packages, a change in a shared dependency can surface in several places at once, and the README's instruction to transpile and polyfill transitive dependencies means your build config is part of the upgrade surface. Budget for re-running your browser target checks, not just for bumping a version number. The CHANGELOG.md and the releases/ directory in the repository are where the project records what changed.

Editorial conclusion

Adopt Turf.js when your data is already GeoJSON and your operations are per-feature geometry work: buffers, measurements, intersections, point-in-polygon tests, classification and statistics, in a browser bundle or in Node. Do not adopt it as a replacement for a spatial database or an index; the README describes a library of operations, not a query engine, and there is no documented indexing layer for large feature sets. Before committing, verify three things in your own build: that your bundler transpiles and polyfills Turf together with its transitive dependencies, that your Node version is an Active or Maintenance LTS release, and that the specific function you need is exported by the module you plan to import, since Turf is split across many packages rather than one file.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Turfjs/turf on GitHub