FAQ

  • Q: Is this library considered finished?

    The library is still in early development, but over the last year the API has been getting more stable and version 1.0 is not that far.
  • Q: What are the future goals of the library?

    The library's overall goals are to continue bringing popular patterns from FP languages into TypeScript.
  • Q: How are new features decided and planned?

    Most of the development stems from dogfooding the library in personal projects.
    User feedback is also extremely important - check out the question at the bottom to see why.
  • Q: Is this library intended to be used on the front-end or the back-end?

    Purify is intended to be used both on the front-end and the back-end.
    Everything from the build config to the API choices and features included is made with this in mind.
  • Q: Is this library intended to be part of an ecosystem of likeminded libraries or handle additional functionality itself?

    Purify is intented to be a single library with a focus on general purpose API.
    Official bindings to popular libraries like React, Angular, Express etc. are not planned and most likely won't happen.
  • Q: What is the timeline for the new releases?

    There are no exact dates for upcoming versions of Purify.
    I try to release a new version every couple of months, but there's no guarantee for that.
  • Q: Should I expect breaking changes?

    The library is in pre-v1 stage, breaking changes are certainly possible.
    Situations in which you can definitely expect breaking changes are:
    There is a new TypeScript release that allows for more type safety
    There is a new TypeScript release that makes expressing certain constructs (like HKTs) possible
    ECMAScript proposals that allow for a more elegant API (like the pipeline operator) reach stage 3

    TL;DR - Breaking changes will be rare, but if the language evolves in a way that makes FP code easier to write then there will be changes for sure.
  • Q: What should future contributors focus on?

    Pull request for bugfixes or documentation improvements are always welcome, but trying to add new methods via a PR most likely won't be accepted.
    Sharing use cases or pain points are the fastest way to see something implemented in the library and I'll greatly appreciate it.