sum-types
eslint-plugin-expect-type
sum-types | eslint-plugin-expect-type | |
---|---|---|
8 | 3 | |
42 | 87 | |
- | - | |
5.9 | 9.6 | |
3 months ago | 7 days ago | |
TypeScript | TypeScript | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
sum-types
-
Either type
I entirely agree about using symbols. sum-types does that.
-
Question about error handling in Typescript
With fp-ts and sum-types you'd handle this functionally like so:
-
type .kind checks vs. class instanceof checks
If you're looking to have discriminated unions like Rust, follow that section to roll your own or look for a library that's already implemented them. fp-ts has everything under the sun in a Haskell style, neverthrow has Rust-like Result and ResultAsync, and sum-types helps with the boilerplate of defining your own sum types.
-
Is there a more graceful way to create dependencies between object key settings?
I'd suggest sum-types. Instead of unsafe user-defined type guards you get safe pattern matching.
-
Best way to store persistent texts?
If you wanted to lean (more) into FP you could replace the Event type and buildPopup function with a sum type and pattern match respectively, as well as represent side effects like in popup with fp-ts' IO, make use of function composition, etc. The former in particular is great for readability:
-
Is there any known way to measure coverage of... types?
You can test types, at least in terms of asserting happy path types and whether a piece of code, runtime or purely type-level, should trigger a tsc type error. Here's an example using eslint-plugin-expect-type.
-
Has the unsoundness (will explain in the post) actually become a pitfall in practice?
Anywhere that overloads are needed will rely upon type assertions or the unsafety implicit in overloads, for example in fp-ts/function::pipe. It'll come up a lot with objects too when there isn't a preexisting primitive you can compose atop of, as in for example fp-ts-std/Record::pick. Something as generic as @unsplash/sum-types has assertions all over the place, though to be fair that's mostly again a case of struggles interacting with object types.
-
How to handle "mutable state" in a pure functional way
You might like @unsplash/sum-types also.
eslint-plugin-expect-type
-
eslint-plugin-expect-type VS vite-plugin-vitest-typescript-assert - a user suggested alternative
2 projects | 18 Jul 2022
- Extreme Explorations of TypeScript's Type System
-
Is there any known way to measure coverage of... types?
You can test types, at least in terms of asserting happy path types and whether a piece of code, runtime or purely type-level, should trigger a tsc type error. Here's an example using eslint-plugin-expect-type.
What are some alternatives?
TypeScript - TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
nominal - Powerful nominal types for your Typescript project
immutable-js - Immutable persistent data collections for Javascript which increase efficiency and simplicity.
vite-plugin-vitest-typescript-assert - 🔥 TypeScript type assertion plugin for vitest
tsd - Check TypeScript type definitions
eslint-plugin-functional - ESLint rules to disable mutation and promote fp in JavaScript and TypeScript.
mori - ClojureScript's persistent data structures and supporting API from the comfort of vanilla JavaScript
lambda-ioc - Super type safe dependency injection 💉 for TypeScript (inspired by Diddly)
Visual Studio Code - Visual Studio Code
typefuck - Type-level Brainfuck interpreter in TypeScript