Copy matchers from monorail/sharedHelpers
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.