Gerrit0

let ajax = (function() {
		/**
		 * Easily make an XHR request.
		 *
		 * @param {string} protocol
		 * @param {string} url
		 * @param {object} params -- WARNING. Only accepts shallow objects.
		 * @return {Promise}
		 */
		function xhr(protocol, url = '/', params = {}, headers = {}) {

Gerrit0

// ==UserScript==
// @name         Inbox Signatures
// @namespace    http://gerritbirkeland.com/
// @version      1.0
// @description  Adds a button to Inbox by Gmail's compose dialog to add a signature.
// @author       Gerrit0
// @match        https://inbox.google.com/*
// @grant        none
// ==/UserScript==

Gerrit0

const { Minimatch } = require("minimatch")

const patterns = [
  // Separate test folder
  '**/{test,node_modules}/**/*.ts',
  // Tests alongside source
  '**/{node_modules/**/*,*.{spec,test}}.ts',
  // Alongside source, including node_modules
  '**/*.{spec,test}.ts',
]

Gerrit0

interface ApiErrorResponse {
  cod: number;
  message: string;
}

interface ApiDayResponse {
  dt: number;
  main: {
    temp: number;
    temp_min: number;

Gerrit0

/**
 * Helper function to find the caret position in a contenteditable element
 * Credit: http://stackoverflow.com/questions/3972014/
 * @param {HTMLElement} editableDiv
 * @return {number}
 */
function getCaretPosition(editableDiv) {
    let caretPos = 0;
    let sel = window.getSelection();

Gerrit0

This is a first attempt at a high level restructure of TypeDoc. There are almost certainly issues with the proposed design that I'm missing or haven't resolved yet. Some of these include

1. How should users modify the JSON output? #930
2. A lot of events are used by TypeDoc's current design, this offers a lot of flexibility for plugins to attach to an event and modify an object at any part of its lifecycle, but makes debugging painful since they are also heavily used internally. Which events should be retained, and which should be removed?
3. Does it make sense for readers to declare their options in the constructor? It is nice to tie the code that uses the option and the code that declares it together, but this could cause problems when using the api programatically.
4. Should some readers exist by default? (TsConfig, TypeDoc)

Goals in this first pass:

1. Define the primary interfaces required to write a CLI

Gerrit0

import * as ts from 'typescript'
import { resolve } from 'path'

const options: ts.CompilerOptions = {
    declaration: true,
    emitDeclarationOnly: true,
    allowJs: true, // I treat jsw as js
    // ...
}

Gerrit0

@{%
const nth = n => d => d[n]
const intrinsic = d => ({ type: 'intrinsic', value: d[0] })
%}

# I skipped function types and object types, running low on time.

Main -> _ Type0 _ {% d => JSON.stringify(d[1]) %}

# Handle precedence, lowest first

Gerrit0

/**
 * Simple, type safe, event emitter class.
 *
 * @example
 * ```ts
 * const x = new EventEmitter<{ a: [string] }>()
 * x.on('a', a => a.repeat(123)) // ok
 * x.on('b', console.log) // error, 'b' is not assignable to 'a'
 * const y = new EventEmitter<{ a: [string]; [k: string]: unknown[] }>()
 * y.on('a', a => a.repeat(123)) // ok

Gerrit0

There are really three kinds of converters in TypeDoc

1. File
2. Modules
3. Library

Each of these may share individual node converters, but they are fundamentally different. File mode creates a globals map. Modules mode creates a map representing the structure of the package. Library mode creates a map describing the project from one or more entry points.

Furthermore, giving each mode its own converter makes it possible for modes which don't care about which nodes are actually used to create a definition to avoid including those implementation details in their documentation. For instance, a module which is re-exported with export * as ns from './f' in library mode should just be another namespace in the documentation, while modules mode should include it as a module, and create a reference.