Skip to content

Copy matchers from monorail/sharedHelpers

Peter Murphy requested to merge pm/add-matchers into dev

Copying sharedHelpers/matchers over from monorail to be used (and open-sourced) as a standalone library. Original is here: https://github.com/Simspace/portal-suite/blob/dev/client/packages/monorail/src/sharedHelpers/matchers.ts

The following considerations were copied over from the Open-Source Process document.

  • Is there an existing library in the open source ecosystem that can be embraced instead? Hopefully this step occurred long before we wrote the code.
    • Have we evaluated the effort it takes to roll our own vs. extend existing functionality of another library/product?
    • Does this work provide genuine and novel value to the community in general?

matchers provides a set of functions for pattern-matching on tagged unions (also known as discriminated unions) in TypeScript. This is how "sum types" are encoded in TS, which is a very useful construct (for example, our ts-gen tool encodes Haskell's native sum types in TS as tagged unions with a discriminant "tag" field), and matchers is accordingly widely used—on dev we are importing from sharedHelpers/matchers in 486 TS files. There are other pattern-matching libraries in the TS ecosystem, such as ts-adt and ts-pattern. ts-pattern covers a more general use case of pattern-matching than just matching on discriminated unions, and is slightly more verbose and has worse developer experience than matchers in that case. ts-pattern also lacks a pipeable/pointfree API and support for returning Option from partial pattern matches. ts-adt is similar in API to matchers, but with less features.

  • Does the code contain proprietary features related to our core business?
    • Does it leak knowledge or give insight integral to our primary product(s)?
    • Can it give a competitor an edge if they were to use it to build a competing product?
  • Does the repository contain any secrets or tokens that need to be scrubbed?
    • Does the usage of these secrets or tokens leak information that could compromise the security of the company or its products?

No to all the above.

  • Is the team willing and capable of acting as a shepherd to the wider open source community? Specifically, can a time commitment be made to support this choice?
    • Reviewing and blessing PRs that could affect our own code base(s)
    • Introducing features that mesh well or diverge from our own product vision
    • Managing the community, especially if it becomes large. Is the company willing to commit resources to full time open source project management?

This is a pretty minimal library, around 350 lines of code and only two dependencies. I don't foresee it being a maintenance burden.

Edited by Peter Murphy

Merge request reports