Show macOS app switcher on all screens
To show the macOS app switcher on all screens:
defaults write com.apple.dock appswitcher-all-displays -bool true
To see the change, restart the Dock with killall Dock.
To show the macOS app switcher on all screens:
defaults write com.apple.dock appswitcher-all-displays -bool true
To see the change, restart the Dock with killall Dock.
This is everything I install and setup on a fresh Mac machine.
For a long time I, someone on my team, would wait for backend pipelines to finish before manually publishing deploys from Netlify. I finally automated it: here's how! (If you have auto-publish turned on for your production deploys, you don't need this.)
If you set --prefer-offline to true in npm, naively thinking (like I did) that this will speed up your npm installs, you will be disappointed (like I was). Annoyingly, this setting causes npm to also cache which packages and versions don't exist. Thus, updating a dependency to a newly published version causes npm to think it doesn't exist and, instead of doing anything about it, npm will simply error out.
Clone a repo with worktrees setup from the start:
mkdir <repo-name>
cd <repo-name>
git clone --bare --filter=blob:none <git-url>
cd <repo-name>.git
Some options to help your sanity:
# always prune on fetch
git config fetch.prune true
# allow `git fetch origin <branch-name>` to work as expected (create a remote ref)
git config remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
To create a new branch:
git worktree add ../<branch-name>
cd ../<branch-name>
To copy a remote branch (note that this will only work with the above fetch config set):
git fetch origin <branch-name>
git worktree add ../<branch-name>
cd ../<branch-name>
To create a new branch based on a remote branch:
git worktree add ../<branch-name> -b <branch-name> --no-track origin/dev
cd ../<branch-name>
This how to enable up/down arrow auto-complete navigation instead of basic history navigation, without installing plugins.
nano ~/.inputrc
Paste in:
"\e[A": history-search-backward
"\e[B": history-search-forward
Run:
bind -f ~/.inputrc
Put the following into your ~/.zshrc:
autoload -Uz up-line-or-beginning-search down-line-or-beginning-search
zle -N up-line-or-beginning-search
zle -N down-line-or-beginning-search
bindkey '^[[A' up-line-or-beginning-search # Up arrow
bindkey '^[[B' down-line-or-beginning-search # Down arrow
To run cron jobs with your user env so that it's actually possible for them to run anything, add this to the top of your cron file (edit with crontab -e):
SHELL=/bin/bash
HOME=/home/<username>
BASH_ENV=$HOME/.bashrc
Then look at your ~/.bashrc file and make sure to remove any code (usually at the top) that exits early if found in a non-interactive shell.
It's really hard to get new Worker() from node:worker_threads to work when running code via tsx. I finally got an example working. Here's how to do it:
import {Worker} from 'node:worker_threads';
const workerPath = import.meta.resolve('./sample-worker.js');
const worker = import.meta.filename.endsWith('.ts')
? new Worker(
`import('tsx/esm/api').then(({ register }) => { register(); import('${workerPath}') })`,
{
eval: true,
},
)
: new Worker(workerPath);
It's super easy to write your own daemon, so here's how.
CJS Node.js scripts have always been able to detect if they're running directly through the CLI or imported from another JS script through various means (the most recent being require.main === module).
However, ESM scripts have not been so lucky. For years the answer to this in ESM has simply been no.
Now it's in Node.js v24! You use it like this:
if (import.meta.main) {
// executed from CLI
} else {
// imported into another JS module
}