type-fest VS tsafe

Related: https://github.com/sindresorhus/type-fest/blob/main/source/o...

Typescript doesn’t natively provide an Opaque type that we can use to define a string that has already been localized. If the data looks like a string, Typescript will consider it a string. We can however use utility types that simulate opaque types, like the Opaque definition in type-fest:

With these powerful features, you can create dynamic and expressive types. One last thing I want to mention before moving on, is that you can install libraries with which you can add more types to your project like type-fest or utility-types. These libraries contain a lot of useful types that you can use in your project.

Also, it’s not as restrictive as mutability tools — if you know what you are doing and want to ignore this limitation for a particular case, you can apply the -readonly modifier or the Writeable type from type-fest or ts-essentials.

Remember you can derive one type from another type so you can make sure they don't diverge. SetOptional type util

Some folks have built whole SQL databases and DSL compilers in the TS type system. These tend to be toy projects with disclaimers not to use them. But the type system being Turing complete[0] (for better or worse), pretty much whatever you can imagine. This project[1] is one I actually return to frequently for practical ideas.

0: https://github.com/microsoft/TypeScript/issues/14833

1: https://github.com/sindresorhus/type-fest

Have a look at SetRequired and SetOptional in type-fest

Try the Exact method provided by Type Fest, looks like it does what you're looking for

This is a fairly common scenario and available via libraries like type-fest or implementable with a couple lines of code.

Hello, This is a use case for tsafe, a utility that let you make assertions on types.

Zod is a solution for generating validators. I used to be reluctant to use it because I like to declare my types with the TypeScript syntax. I am not satisfied by getting the type inferred from the validator. The solution I found is to use tsafe, a utility that enables to make sure that two types are equals. With this solution you'll have to declare your type twice, once with the TypeScript syntax and once when declaring your zod parser but you are garentied that if you update your type and forget to update the corresponding zod parser your app won't build.

tsafe.dev

Hi, Checkout tsafe. It enables to test types definition. Checkout this GIF in particular. Let's say for example that we have an objectFromEntries function and we want to test it typewise, we can do: ```typescript import { objectEntries } from "../myObjectFromEntries"; import { assert } from "tsafe";

`Object.fromEntries()`, `Object.entries()` and `Object.keys()` are barely usable when in a TypeScript codebase because their return type are very vague. [tsafe](https://github.com/garronej/tsafe) features three new utilities: [objectFromEntries()](https://docs.tsafe.dev/objectfromentries), [objectEntries()](https://docs.tsafe.dev/objectentries) and [objectKeys()](https://docs.tsafe.dev/objectkeys), functionally equivalent to their built-in counterpart but featuring much better return types.

Three GIFs to convince you that you need tsafe in your life: