cspotcode - Andrew Bradley

Configuring a basic TypeScript composite project

2020-02-26T00:00:00+00:00

Sometimes I forget the cleanest way to configure a tsconfig composite project with separate tsconfigs for src and test. Here’s the latest template that I use. tsc --showConfig is helpful to validate that it’s doing the right thing.

This configuration is pretty straightforward:

source in src is emitted to dist
tests in test will be run via ts-node or similar, so they do not need to be emitted.
anything else, such as ts-node dev scripts or an ./examples directory, is handled by the root tsconfig file, and is not compiled.

tsconfig.json

{
    // If in a monorepo, extend from the base config
    "extends": "../../tsconfig.json",
    "references": [
        {
            "path": "src"
        },
        {
            "path": "test"
        }
    ],
    // Exclude references and emitted output
    "exclude": ["src", "test", "dist"],
    "compilerOptions": {
        "composite": true,
        "rootDir": ".",
        
        // We can't pass "noEmit" in incremental mode, but this is close enough.
        "outDir": ".tmp/tsc/root",
        "emitDeclarationOnly": true
    }
}

src/tsconfig.json

{
    "extends": "../tsconfig.json",
    "exclude": [],
    "compilerOptions": {
        "rootDir": ".",
        "outDir": "../dist",
        "emitDeclarationOnly": false
    }
}

test/tsconfig.json

{
    "extends": "../tsconfig.json",
    "references": [
        {
            "path": "../src"
        }
    ],
    "exclude": [],
    "compilerOptions": {
        "rootDir": ".",
        "outDir": "../.tmp/tsc/test"
    }
}

Emulate JavaScript’s proposed pipeline operator with a helper function

2020-02-12T00:00:00+00:00

JavaScript’s proposed pipeline operator has been stuck at stage 1 for a long time, and I’m skeptical it’ll ever be added to the language.

It’s easy to emulate with a helper function. You have to type a few extra characters, but once the code’s written, it’s very readable and gets the job done.

Playground link

interface Pipeline<T> {
    <R>(cb: (v: T) => R): Pipeline<R>;
    value: T;
}
function pipe(): Pipeline<undefined>;
function pipe<T>(value: T): Pipeline<T>;
function pipe(value?: any): any {
    function chain(cb: any) {
        return pipe(cb(value));
    }
    chain.value = value;
    return chain as any;
}

function add(a: number, b: number) {
    return a + b;
}
declare function subtract(a: number, b: number) {
    return a - b;
}

const r = pipe()
    (_ => add(2, 3))
    (v => subtract(v, 2))
    .value;

Implement bash profile functions as external executables

2020-01-29T00:00:00+00:00

Sometimes a shell helper needs to set variables in your shell session, for example to modify your PATH. An external executable can’t do this, so these functions need to live inside your bash shell. Typically this means writing the functions in bash (gross) or dot-sourcing a large, external chunk of bash, which slows shell startup.

One way around this is to write the helper function in a real language and put a tiny adapter in your shell profile.

# In your shell profile
add-env-to-path() {
    { eval "$( ~/scripts/add-env-to-path.ts "$@" 3>&1 1>&4 )" ; } 4>&1
}

This adapter will call an external executable but capture instructions from file descriptor 3. It’ll then eval them in the shell. The external executable can, at its discretion, write valid shell syntax to file descriptor 3, for example to modify the PATH.

#!/usr/bin/env ts-script
// ~/scripts/add-env-to-path.ts
console.log('Interact via stdout and stdin because those FDs are passed verbatim.');
const environment = prompt('Which environment should be added to PATH?'); // pseudocode, but you get the idea
fs.writeSync(3, `
PATH=${ shellEscape(`${ Path.join(os.homedir(), '.envs', environment) }:${ process.env.PATH }`) }
`);

The magic is the switcheroo between file descriptors 3 and 1. Bash $() syntax passes a new stdout file descriptor, whose output is captured, to the child process. Instead, we want to capture the child process’s output to file descriptor 3, passing the original stdin, stdout, and stderr as file descriptors 0-2.

Enforce comprehensive keyof array in Typescript

2019-06-24T00:00:00+00:00

I had a situation where I wanted to ensure an array of keyof T included all keys of that interface. This could be useful in situations where you need to keep some runtime type information in sync with a compile-time interface.

Here’s the exact code in question, but this trick could be applied to other situations. In this situation, I want to normalize a notifier object. It may or may not contain any number of callbacks; I need to replace all the missing ones with noop functions. Otherwise I’ll get runtime errors when I try to fire those callbacks elsewhere.

function createNotifier<T, Key extends keyof T>(n: T | undefined): never;
function createNotifier<T, Key extends keyof T>(n: T | undefined, ...keys: Array<Key>):  keyof T extends Key ? Required<NonNullable<T>> : never;
function createNotifier(n: any, ...keys: any) {
    const n2 = n ? n : {} as any;
    for(const key of keys) {
        if(!n2[key]) n2[key] = noop as any;
    }
    return n2 as any;
}

The function accepts an array of keyof T. To prove that this array is comprehensive (doesn’t omit any properties) I use a conditional type in the return. Basically I flip the extends backwards: keyof T extends Key instead of Key extends keyof T. If that check fails, the function returns never which is sure to show up as an error elsewhere in my code. I suppose I could also return "error": "HELPFUL ERROR MESSAGE"}

Multiple function signatures are necessary to account for the case where zero keys are passed to the function. In that case, inference sets Key equal to keyof T, which allows our validation in the second function signature to erroneously pass. We avoid that by adding the first function signature. If zero keys are passed, the function returns never.

Hide Windows Updates Programmatically

2019-06-09T00:00:00+00:00

My company gives us Office 2010, but I have my personal copy of 2019 installed instead. For some reason, Windows Update keeps proposing Office 2010 updates which always fail to install.

PSWindowsUpdate is a PowerShell module for interacting with Windows Update interactively or programmatically. It allows hiding windows updates.

install-module -scope currentuser pswindowsupdate
hide-windowsupdate

This will query Windows Update for updates then prompt you to hide all of them one by one. I had to run it a bunch of times, since each batch of update hiding allowed Windows Update to find others, probably because at this point there are months of Office 2010 updates that don’t apply to me.

Polyglot PowerShell and bash script

2019-06-01T00:00:00+00:00

I wanted to put some bash and some PowerShell into the same script file, so if I ran it in bash it would do one thing, and if I ran in PowerShell it would do something else. Here’s what I came up with:

#!/bin/bash
echo `# <#`

# Bash goes here
set -euo pipefail

ls -al doing bash stuff

exit
#> > $null

# PowerShell goes here

$val = (
    'powershell',
    'stuff',
    'here'
)

foreach($v in $val) {
    # yadda yadda
}

The magic is here:

echo `# <#`
# bash code
exit
#> > $null
# powershell code

On bash, it executes what’s between the backticks, which is just a comment. So it succeeds silently and passes through to the bash script. We exit before it gets to any PowerShell syntax.

On PowerShell the backtick is an escape character, so `# is parsed as the string "#". It’s followed by a multiline comment delimited by <# #>, so PowerShell skips over all our bash code. We redirect to $null to suppress the echoed #.

Attach VSCode to container from CLI

2019-05-30T00:00:00+00:00

VSCode’s new “Remote development” features let you attach the editor to a remote system, for example, WSL, an SSH server, or a docker container.

The WSL integration lets you run code-insiders . from WSL, and it opens the current directory in a VSCode window automatically connected to WSL. However, it wasn’t obvious how to do the same for attaching to a docker container. After reading some of the code, I figured it out:

auth="attached-container+$(node -p 'Buffer.from(process.argv[1]).toString("hex")' "$containerId")"
code-insiders --remote="$auth" --folder-uri="vscode-remote://$auth/path/inside/container"

How it works:

As far as I can tell, VSCode lets you specify a --remote flag of the form <authority>+<target>

<authority> is one of dev-container, attached-container, or wsl. <target> depends on the type. For WSL, a target of default will attach to the default WSL distro. For attaching to a container, the target should be the hex-encoded container ID. We can compute this using a node one-liner.

Technically, it looks like the <target> can also be a JSON object converted to hex, where the JSON object contains multiple fields. I think this is used for the dev-container authority to specify both a local directory and a docker host.

To attach using a devcontainer configuration, the <authority> is dev-container and the <target> should be one of the following hex-encoded:

path of the project on the host
JSON of the form:

{hostPath: "/home/me/whatever", dockerHost:"I assume a docker host domain name and port goes here"}

Bash prompt zero-width spans

2019-03-03T00:00:00+00:00

I had a lot of trouble setting up a bash prompt that renders within an external function, rather than inline within the PS1 string. Zero-width sequences from this external function were instead rendering \[ and \] on the console.

PROMPT_COMMAND=prompt
function prompt {
    status_info="< generate a bunch of status info here>"
}
PS1='$status_info'
> '

Zero-width byte sequences in PS1 need to be wrapped with \[ and \] so that bash can compute the correct visual width of the prompt.

It wasn’t immediately clear that bash special-cases \[ and \] character sequences within PS1, converting them into bytes 1 and 2. External variables and functions being interpolated into the PS1 string need to contain 1 and 2 byte values, not the 2-character \[ \] sequences.

https://unix.stackexchange.com/questions/504150/emit-zero-width-bash-prompt-sequence-from-external-binary

Create an orphaned, empty tree branch in Git

2019-03-03T00:00:00+00:00

This blurb creates a git branch with a single, parent-less commit, with an empty tree. In other words, it’s an orphan with a commit but no files.

You can achieve this by checking out an orphaned branch and then commit --allow-empty. However, the blurb below doesn’t require you to switch your worktree to a new branch.

I’ve used this trick when I want to commit a subdirectory into a new, empty branch. I pass this branch to git worktree add -b new-branch dir-name empty-orphan.

# Create and save an empty tree object
treehash="$( git hash-object -w -t tree /dev/null )"
# Create a parent-less commit with empty tree
commithash="$( git commit-tree "$treehash" -m "Empty tree" )"
# Create an orphan branch at the new commit
git branch empty-orphan "$commithash"

Load nvm on-demand

2018-08-16T00:00:00+00:00

nvm startup is slow on WSL. This is WSL’s fault, not nvm’s. All the process forking in nvm’s startup is slow. My work machine’s corporate virus scanner might be exacerbating the problem.

Regardless, it’s easy to load nvm on-demand via bash profile. I rarely invoke the nvm command; I just need node and npm in my $PATH.

Default nvm loader:

# nvm puts this in your .bashrc
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

Change it to this:

export NVM_DIR="$HOME/.nvm"
function nvm {
    [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
    [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion
    nvm "$@"
}
PATH="/home/abradley/.nvm/versions/node/$( cat /home/abradley/.nvm/alias/default )/bin:$PATH"

There might be some corner-cases not handled when I set the PATH, but it works for me.