Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time
February 3, 2023 14:38
April 7, 2023 16:34
October 30, 2020 11:44
November 11, 2020 21:49
April 10, 2023 12:50
November 2, 2020 10:11
February 3, 2023 14:38
February 3, 2023 14:38
February 3, 2023 15:36
April 10, 2023 12:50
May 7, 2022 23:28
February 3, 2023 15:21


The missing pseudo-standard library for fp-ts.



The library is available on the npm registry under the same package name: fp-ts-std

fp-ts, newtype-ts, and monocle-ts are listed as peer dependencies.

fp-ts-std is published with both ESM and CJS modules. The import paths in either case needn't change and the appropriate module resolution should be picked up by Node and your bundler, however if your environment doesn't support conditional exports you'll need to import directly from a dist/(cjs|esm)/ subdirectory. Given ESM modules the library should tree shake well.

Node LTS - at time of writing v18 - and the latest evergreen browsers are supported.


fp-ts-std aims to achieve the following objectives:

  • Flesh out what fp-ts is missing
  • Fill in the gaps between fp-ts and Ramda
  • Wrap JS APIs to be friendly, so that you never have to interact with null or undefined, or worry about a function throwing again


fp-ts-std strives to adhere to the following principles:

  • Strict type-safety wherever possible, with risks well documented
  • All functions are curried
  • Functions are data-last as a rule
  • Functions are total unless explicitly prefixed with "unsafe" (with the exception of the Debug module)
  • Impure functions are appropriately signed with the IO and Task types
  • Lean towards Haskell naming conventions and idioms with an eye to fp-ts norms

Additionally, fp-ts-std enforces 100% testing coverage, and just about everything is documented with examples.


Unreleased work is commit to the develop branch. master is the release branch and whence the documentation is generated.

All modules and exports must be annotated with JSDoc. This information is used to generate documentation. Simple, illustratory tests can also be included and will be checked during docs generation. For more information, see docs-ts.