Today I learned about...
typescript

TIL about ts-reset - it’s like CSS resets but for TypeScript! Shout out to Matt Pocock (and the team) for this!

Here’s an example of one of the rules:

import '@total-typescript/ts-reset/array-includes'

const users = ['matt', 'sofia', 'waqas'] as const

// .includes now takes a string as the first parameter
// BEFORE, it would have complained about the type of the first parameter
users.includes('bryan')

There are way more rules so I encourage you to give it a read and maybe incorporate it into your project!

Check it out

TIL about the Standard Schema! It’s an effort to standardize the interface of TypeScript validation libraries.

To pull directly from the docs, The goal is to make it easier for ecosystem tools to accept user-defined type validators, without needing to write custom logic or adapters for each supported library.

TIL about how one can use satisfies in typescript, without satisfy at all!

// taken right from Kent's blog
type OperationFn = (left: number, right: number) => number

// this is a restriction on the operations object
// but with satisfies, I leave myself room to add more operations and don't need to manage another type
const operations = {
	'+': (left, right) => left + right,
	'-': (left, right) => left - right,
	'*': (left, right) => left * right,
	'/': (left, right) => left / right,
} satisfies Record<string, OperationFn>

Check it out

TIL there’s a tool that can help you find out if your types are wrong for your library!

Check it out

Want to have some type hinting for a union but allow any string value?!

Use this hack bruh:

type color = 'red' | 'blue' | 'green' | (string & {})

function getColor(c: color) {
	console.log(c)
}

getColor('red') // editor will code complete this for you
getColor('yolo') // this works!

Today I learned about Typescript execute (I’m using it on my website now too 😆). It’s a CLI alternative to node for running Typescript & ESM!

Check it out

TypeScript has a handy utility type to extract types from a union type 🤭.

type MyUnion = 'Hello' | 'Mom' | 'I' | 'Love' | 'You'
type WithoutMom = Extract<MyUnion, 'Mom'>
// the above will be the type "Hello" | "I" | "Love" | "You"

TIL that there’s a TS utility type that does the opposite of Partial.

Check it out

Want to make it so that people need to provide some sort of generic argument if they don’t use some predefined defaults for your TS code. Check this out:

type NoInfer<T> = [T][T extends any ? 0 : never]

type QT<T> = 'first' | 'second' | T
type Yolo<T> = {
	data: QT<T>
}

function doSomething<T = void>(args: Yolo<NoInfer<T>>): null {
	// do something
	return null
}

doSomething({ data: 'first' }) // okay
doSomething({ data: 'three' }) // not okay
doSomething<'three'>({ data: 'three' }) //okay

Alright, so I’ve been writing TS for a while and was never really sure why we needed these .d.ts files… until today.

The purpose of these files is so that authors/the community can backport popular JS libraries with TS type definitions. This allows library authors the freedom to keep on writing their JS code but allows users of TS to benefit with working code and the typings they need.

These typings probably exist in something like Definitely Typed. However, at work, we’re using a mix of JS and TS (JS is for the jest setup code) and therefore we were required to have ambient TS files so that our TS test code could benefit from the typings related to our JS files.

We are using module aliasing for our TestUtils so that we can do things like import { render } from 'TestUtils'. Under the hood, the render function is just a nicely wrapped render function from react-testing-library and so the return types are the same. There was a bug where if I tried to import the RenderResult from the testing library, VS code’s TS language server would yell at me for having an undefined module. The following code highlights the fix/issue.

// TYPESCRIPT IS A PAIN
// https://stackoverflow.com/questions/39040108/import-class-in-definition-file-d-ts/51114250#51114251
declare module "TestUtils" {
  export function render(
    v: any,
    other?: { initialState?: any }
  ): import("@testing-library/react").RenderResult
}

// doesn't work
import { RenderResult } from "@testing-library/react"

declare module "TestUtils" {
  export function render(v: any, other?: { initialState?: any }): RenderResult
}

React.FC was more meant to help beginners get more comfortable writing React components with TS but honestly, the cons of using it (always having the ability to pass children to your component even though you might not be rendering said children) make me want to not use it.

If you’re wanting to type children, you can do:

type Props = {
	children?: React.ReactNode
}

Turns out TS has some conditional types!

T extends U ? X : Y

If T extends U, then T is type X otherwise it is type Y.

Check it out

There’s a neat little utility type in TypeScript that lets you reach into a function and discern the types of the function arguments.

Parameters<(s: string) => void>
// [s: string]

Check it out