fast-csv splits parsing and formatting into two packages and a wrapper

Choose the wrapper or one of the two halves

fast-csv is not one package on npm. The project publishes three, and the README describes the choice explicitly.

`fast-csv` is the one-stop shop that re-exports every method and option from both halves. `@fast-csv/parse` is for code that only reads delimited files. `@fast-csv/format` is for code that only writes them.

That split is the practical decision at install time. A service that only ingests exports should depend on `@fast-csv/parse` and never pull the writer; a job that only emits reports should take `@fast-csv/format`. The wrapper is for code that genuinely does both, and it exists so you are not importing from two packages by hand.

The scope is wider than CSV. The README describes it as a library for parsing and formatting CSVs or any other delimited value file, which matters because "delimited" covers the tab-separated and pipe-separated exports that come out of legacy systems more often than real CSV does.

Licensing is MIT, so there is no copyleft obligation on anything you build with it.

Streams first, and what that actually changes

The design claim in the README is that the library is built with streams first to avoid creating a large memory footprint when parsing large files. That is a specific architectural choice, not just a marketing line: the parser consumes a readable stream and emits rows as they are parsed, so a multi-gigabyte export does not have to be materialised as an array of objects before your code sees the first row.

The practical consequences follow from that. You write a row handler rather than awaiting a result, and backpressure is handled by the stream pipeline rather than by you buffering. If your use case is a small file that you want as a plain array of objects, a stream-first library still serves you, but the shape of your code is different from a synchronous parse call.

The README also claims a scale figure, stating the library is used in production parsing and formatting millions of records every day. That is an assertion by the maintainers rather than a benchmark you can reproduce from the repository, and it is worth treating as such when you are sizing your own expectations.

The option surface lives in the documentation, not the README

The README is short by design. It lists formatting and parsing options as a feature and links to two separate pages on the docs site, one for formatting options and one for parsing options, describing them as flexible enough to fit almost any scenario.

That is where the real API documentation is, along with the install page and getting-started pages for each of the three packages. If you are evaluating this library, the formatting options page and the parsing options page are the two documents to read, because the decisions that matter for correctness, delimiters, quoting, headers and how malformed rows are treated, are configuration decisions rather than API decisions.

The README itself contains almost no code, and the project does not include a quick start snippet inline. If you prefer to work from the repository, the examples directory has the material: parallel folders for formatting and parsing, in both JavaScript and TypeScript, named formatting-js, formatting-ts, parsing-js and parsing-ts, plus a benchmark directory, an example runner, and standalone fast-csv-js and fast-csv-ts folders. Running those examples locally is a more reliable way to see current behaviour than reading an old blog post about a version from years ago.

A monorepo built on pnpm, lerna and renovate

The repository root is not the package. Its manifest is marked private and its scripts delegate everything to workspaces.

{
    "private": true,
    "packageManager": "[email protected]",
    "engines": {
        "node": ">=20.0.0",
        "pnpm": ">=10.34.4"
    }
}

Workspaces cover packages/*, examples/* and documentation, which is how one command can build and test all three published packages plus every example. Builds go through `lerna run build`, releases go through `pnpm run build && pnpm run lerna:version && pnpm run lerna:pub`, and versioning uses the conventional commits flow with a commitlint config at the root.

The toolchain is deliberately strict. Linting runs eslint with `--max-warnings 0`, so a single warning fails the build. Tests run jest in band with coverage, and `pnpm run test` chains lint, jest and the examples, which means the examples are part of the merge gate rather than documentation that drifts. Prettier handles formatting across ts, js, json, md, mdx and css.

Two housekeeping files say something about the project's posture. renovate.json is present, so dependency updates are automated, and security-vulnerabilities-pending-min-age.md suggests there is a policy around how long a known vulnerability is allowed to sit before it is patched. The engines field is the version constraint contributors must respect: Node 20 or newer.

Release rhythm and what it means for upgrading

The repository is not archived and the last push was on 2026-10-16. Recent releases on the 5.x line are v5.0.8 on 2026-10-05, v5.0.7 on 2026-05-06 and v5.0.5 on 2025-08-04.

The gaps between those dates are wide, which suggests patches rather than a feature cadence. That has a direct consequence for anyone deciding whether to pin: the minor version has not moved, so the questions to ask are about patch releases rather than about migrating between majors, and the CHANGELOG.md at the repository root is the place to confirm what changed.

Staying on the 5.x line means Node 20 as a floor, since that is what the root manifest declares for development. Nothing in the README suggests support for older Node versions, and no README text discusses a deprecation schedule, so the practical advice is narrow: read CHANGELOG.md before bumping the patch, and run the examples suite after bumping anything.

Where fast-csv is the wrong choice

Three situations argue against it.

First, if your workload is small CSV files read once inside a script, a stream-first library is more machinery than the problem needs, and the code you write will be longer than the obvious split-on-comma version.

Second, if you run Node below version 20 in production, the declared engine floor rules the library out regardless of how well it fits the task.

Third, if your problem is not delimited text. The library is scoped to parsing and formatting delimited values; it is not a database loader, it does not do schema inference, and nothing in the README describes fixed-width or record-oriented formats.

The comparison worth naming is the alternatives layer. A general-purpose data framework can read and write CSV as one format among many, at the cost of bringing an ORM and its conventions with it. fast-csv inverts that trade: a single format done carefully, with separate entry points for the read and write halves so an import job pays only for the parser.

Editorial conclusion

fast-csv fits services that stream CSV in and out through Node and want one set of formatting and parsing options across both directions, with the option reference sitting on a hosted docs site rather than in the README. It does not fit a codebase that needs synchronous whole-file parsing or a runtime below Node 20, since engines pins node to 20.0.0 or newer. Verify first by reading the formatting options and parsing options documentation and confirming that your required behaviours, such as quote handling, delimiters and header behaviour, are covered there before wiring it into an import pipeline.

Frequently asked questions

Official sources

1. C2FO/fast-csv on GitHub
2. License: MIT
3. Project website
4. README
5. Releases