Aditya Agarwal itaditya

By using ReturnType we don't have to manually write ContextType

OpenAPI TypeScript Generator

First we start off with a very generic module for executing OpenAPI operations:

export interface ApiRequest {
  path: string;
  method: string;
  params?: Record<string, string>;
  queryParams?: Record<string, string>;

Location - The location of the application. Usually just a URL, but the location can contain multiple pieces of information that can be used by an app
1. pathname - The "file/directory" portion of the URL, like invoices/123
2. search - The stuff after ? in a URL like /assignments?showGrades=1.
3. query - A parsed version of search, usually an object but not a standard browser feature.
4. hash - The # portion of the URL. This is not available to servers in request.url so its client only. By default it means which part of the page the user should be scrolled to, but developers use it for various things.
5. state - Object associated with a location. Think of it like a hidden URL query. It's state you want to keep with a specific location, but you don't want it to be visible in the URL.

	export class Cache<T extends object, K> {
	items = new WeakMap<T, K>()

	get<P extends T>(item: P, cb: (item: P) => K) {
	if (!this.items.has(item)) {
	this.items.set(item, cb(item))
	}
	return this.items.get(item)!
	}

	function run(input, parameters) {
	const appNames = [];
	const skipAppNames = [];
	const verbose = true;

	const scriptName = 'close_notifications_applescript';

	const CLEAR_ALL_ACTION = 'Clear All';
	const CLEAR_ALL_ACTION_TOP = 'Clear';
	const CLOSE_ACTION = 'Close';

	/*
	This is not meant to be a final CSSWG proposal,
	but reflects my immediate thoughts after reading
	[David Baron's](https://github.com/dbaron/container-queries-implementability) promising draft.
	This gist was created to demonstrate my idea for removing selectors from his query syntax.

	More of my thoughts & notes are online at css.oddbird.net/rwd/
	*/

	main,

	function sign(name, fontSize = 96) {
	// assumes the id of the canvas element is 'canvas'
	const canvas = document.getElementById('canvas')
	const ctx = canvas.getContext('2d');
	ctx.font = `italic ${fontSize}px Snell Roundhand`;
	const signatureWidth = ctx.measureText(name).width;
	const x = canvas.width/2 - signatureWidth/2;
	const y = canvas.height/2 + fontSize/2;
	ctx.fillStyle = ctx.strokeStyle;
	ctx.fillText(name, x, y);

	/**
	* Sometimes you want to programmatically force a Jest test failure. For example, mocking "console.warn()" to
	* make tests fail if they print warning messages to the console. Throwing an error isn't sufficient, because
	* the calling code may be in a try/catch block.
	*
	* Jest has no "fail()" method** to automatically trigger a test failure, but you can do it with an "expect()" matcher
	* that will always fail, such as "expect(true).toBe(false)". This will fail the test, but the output isn't very
	* self-explanatory. You can improve on it by providing a message string as one of the arguments:
	* "expect(null).toBe('Automatic Failure!')". This is better, but the output is still a little confusing, saying
	* it expected "null" and received "Automatic Failure!"

	function killport {
	echo '🚨 Killing all processes at port' $1
	lsof -ti tcp:$1 \| xargs kill
	}