Sometimes you might need to convert snake or hyphen case to camel case or convert a whole type from underscores to camel case. Anyways I got you.
type UpperFirst<T> = T extends `${infer First}${infer Rest}` ? `${Capitalize<First>}${Rest}` : T;
type SnakeToCamel<T, D extends string = '_' | '-'> =
Since nobody asked for it -- I thought I'd parse CSV into objects, instead of arrays of arrays. Yes I know Arrays are objects but I mean the other kind, the object kind of objects.
type Line<T, D extends string = ',', R extends string[] = []> =
T extends '' ? R :
T extends ` ${infer Rest}` ? Line<Rest, D, R> :
Ever need to parse CSV with TypeScript, no? Me niether but here goes.
I redid this one so that can handle quotes more correctly. No that CSV actually parsable, but at least it may almost might be right. I'd like to add csv to objects instead of array of arrays... but I gotta think on that.
type Line<T, D extends string = ',', R extends string[] = []> =
T extends '' ? R :
Say you have a string type and you want to conver to an tupple(array) type. I dunno why, maybe your writing some bad ass TypeScript and this seemed smart.
Enjoy it here
type StrToChars<T, A extends string[] =[]> = T extends '' ? A : T extends `${infer C}${infer Rest}` ? StrToChars<Rest, [...A, C]> : A;
type A1 = StrToChars<'1a3'>;
type A2 = StrToChars<'1'>;
Ever want to make sure parens are balanced in a TypeScript Types, probably not, but (you never know?
see it live
type MatchParens<T> = T extends `${string}(${infer Content})${string}` ? MatchParens<Content> :
T extends `(${string}` | `${string})` ? false : true;
type P1 = MatchParens<'(hello)'>
type P2 = MatchParens<'(hello(more))'>
Ever want to parse query strings with TypeScript Types, well now you can. (Why you would i dunno.)
In action here
type Append<T,K> = T extends Array<any> ? [K, ...T] : T extends undefined | never ? K : [K,T];
type KVObj<O extends {}, K extends string,V> = K extends keyof O ? {[k in K]:Append<O[K],V>} : {[k in K]:V} & O;
Have you ever wanted to parse numbers with typescript types. Me neither, but just in case I ever do, I wrote some types to do just that
/**
* Only supports Base10 numbers, for JSON like parsing.
*/
type Numbers = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ;
type E = 'e' | 'E';
| #!/usr/bin/env bash | |
| # Shamelessly borrowed from https://betterdev.blog/minimal-safe-bash-script-template/ | |
| set -Eeuo pipefail | |
| trap cleanup SIGINT SIGTERM ERR EXIT | |
| script_dir=$(cd "$(dirname "${BASH_SOURCE[0]}")" &>/dev/null && pwd -P) | |
| usage() { | |
| cat <<EOF |
The longest trend in software development.
If you write a function, have some paths that don't return anything. The longer the function the better this works. The caller will never know what to expect. Also don't always return the same thing. Creative thinking like this make relationships work.
Most languages care a lot about parameter order, but you don't have to. Trust your gut and do whatever. Optional, snoptional it can go first. Better yet in the untyped languages figure out what the parameters are. This is where not documenting things really shine.
Typescript 4.1 introduces recursive types and string literals, which
will finally allow one to type the ubiquitous get functions.
Often in JS we want to safely descend an object tree. Without having to null check all the way down. So people for generations have written various get implementations, but they all more or else look like