DEV Community: Douglas Moura

Introducing chroncal: A Terminal-First Calendar, Todo, and Journal Manager

Douglas Moura — Sun, 14 Jun 2026 13:44:04 +0000

I have been building chroncal over the past several weeks, and today I am opening it up. It is a terminal calendar, todo, and journal manager written in Go, backed by SQLite, with broad iCalendar (RFC 5545) import/export coverage and CalDAV sync. You get an interactive TUI for day-to-day use and a full CLI for scripting and automation. Your data lives in a single local file, portable and standards-compliant.

This is the tool I wanted for myself: something that feels like lazygit for calendars, works offline, talks to CalDAV servers (including Google Calendar), and stays out of the way when I just want to check my next meeting.

What it does

chroncal covers three resource types that normally live in separate apps:

Events (VEVENT) — scheduling with recurrence, timezones, attendees, alarms, and attachments
Todos (VTODO) — task management with due dates, priority, progress tracking, and recurrence
Journals (VJOURNAL) — daily notes and journal entries with recurrence support

All three support create, read, update, delete, search, and iCal import/export. All three sync over CalDAV. Soft-delete and restore are built in, so nothing is lost by accident.

The TUI

Run chroncal with no arguments and you get an interactive terminal interface with month, week, day, and agenda views. Switch views with m, w, d, a. Calendars live in a sidebar with color coding. You can create, edit, view, and delete events without leaving the keyboard, and u undoes a delete.

CalDAV sync health is visible at a glance: a calendar whose last sync failed shows a warning icon in the sidebar, and opening it explains what went wrong and offers a fix. Remote calendars can be connected and re-authenticated directly from the TUI, including the Google OAuth flow.

The TUI ships two built-in themes. system is the default and resolves its UI colors from your terminal's 16-color ANSI palette, so themed setups like Catppuccin, Gruvbox, Tokyo Night, or Omarchy carry through to chroncal. It also adapts the selected-row highlight to the live terminal background when the terminal reports it. default uses a fixed light/dark designer palette if you prefer a consistent look across machines.

The CLI

Every operation available in the TUI is also available as a CLI command, and the CLI goes further — full todo and journal management live here. This makes chroncal scriptable in ways that GUI calendar apps cannot match.

# Create a calendar
chroncal calendar create "Work" --color "#3B82F6"

# Add an event
chroncal event add "Team standup" --date 2026-04-01 --time 09:00 --duration 30m --calendar Work

# Add a recurring event
chroncal event add "Weekly review" --date 2026-04-04 --time 14:00 --duration 1h --rrule "FREQ=WEEKLY;BYDAY=FR"

# Add a todo
chroncal todo add "Write quarterly report" --due 2026-04-15 --priority 1

# Add a journal entry
chroncal journal add "Weekly notes" --date 2026-04-04 --calendar Work

# List upcoming events
chroncal event list --from 2026-04-01 --to 2026-04-30

# Search
chroncal event search "standup"

JSON output for scripts and LLMs

Every command accepts -o json (or --output json). The output shape is stable, write commands return the new row so you can capture the id or uid, and errors go to stderr so piping through jq is always safe.

# Round-trip: create then read back the new event
uid=$(chroncal event add "Demo" --date 2026-06-01 --time 09:00 --output json | jq -r .uid)
chroncal event get "$uid" --output json

Timestamps in JSON are RFC 3339 UTC with a Z suffix, so cross-machine comparisons stay honest. Errors emit a JSON object on stderr with a code field (not_found, invalid_input, aborted, or error), so you can dispatch programmatically. This makes chroncal straightforward to drive from shell scripts, CI pipelines, or language model agents.

CalDAV sync

Sync is per-calendar: each local calendar can be linked to a remote CalDAV URL. There is no separate account concept. Connect a calendar at create time:

chroncal calendar create "Work" \
    --remote-url https://cal.example.com/dav/calendars/work/ \
    --username alice --auth basic

Then sync and check status:

chroncal sync run --calendar Work
chroncal sync status

chroncal has been tested against Nextcloud CalDAV with VEVENT, VTODO, VJOURNAL, and VALARM round-tripping, including recurrence, timezone handling, and conflict resolution. Conflicts can be resolved with --pick {local,server}, and the default strategy is configurable.

Google Calendar

Google Calendar requires OAuth 2.0 and only supports VEVENT over CalDAV. chroncal handles the full OAuth PKCE flow: you provide a Desktop app client ID and secret (the secret is accepted via environment variable or interactive prompt, never as a CLI flag), authorize once in the browser, and subsequent syncs run unattended. You can also connect and re-authenticate Google calendars directly from the TUI.

One important detail: you must enable both the Calendar JSON API and the CalDAV API on your Google Cloud project. The CalDAV endpoint returns 403 accessNotConfigured until caldav.googleapis.com is enabled, even if the Calendar API is already on.

Credentials are kept separate from the calendar database. SQLite stores calendar data and remote metadata, but passwords, bearer tokens, OAuth refresh tokens, and Google client secrets go through the OS keyring by default. If a keyring is not available, chroncal refuses to store secrets unless you explicitly pass --allow-plaintext; that fallback writes 0600 JSON files under your chroncal config directory. It is useful for servers and containers, but backups and sync tools can still read those files, so I recommend using a real keyring on shared machines.

Alarms and notifications

Alarms are first-class. Attach them when creating or updating events and todos with --alarm:

chroncal event add "Standup" --date 2026-06-15 --time 09:00 --alarm "-PT15M"
chroncal event add "Release" --date 2026-06-15 --time 14:00 --alarm "DISPLAY:-PT30M::3:PT5M"

The alarm syntax maps to RFC 5545 VALARM: ACTION, TRIGGER, REPEAT, DURATION, and RELATED. A bare -PT15M is a standard iCalendar duration trigger, meaning 15 minutes before the event or todo starts. The longer form is there when you need repeated alarms or an alarm relative to the end instead of the start.

DISPLAY alarms pop desktop notifications, AUDIO alarms play a sound, and EMAIL alarms send mail through a configured SMTP server. To actually fire alarms, either run chroncal alarm daemon in a foreground loop, or install a background service with chroncal service install — which sets up a systemd timer on Linux, launchd agent on macOS, or Scheduled Task on Windows. The installed service also runs CalDAV sync on a configurable interval (default 15 minutes).

iCal compatibility

chroncal aims for complete RFC 5545 compliance. Current coverage includes VEVENT (30/31 properties), VTODO (31/32 properties), VJOURNAL, VALARM (7/7 properties plus RFC 9074 UID support), full ATTENDEE/ORGANIZER parameter coverage, VTIMEZONE round-trip preservation, and VFREEBUSY local compute plus remote CalDAV queries.

You can import from Google Calendar, Apple Calendar, Thunderbird, or any RFC 5545-compliant source, and export produces standards-compliant .ics files:

chroncal ical import calendar.ics --calendar Work
chroncal ical export --calendar Work -f work.ics

Free/busy queries

Compute busy time from local recurring data, or query a remote CalDAV server:

chroncal freebusy --calendar Work --from 2026-04-01 --to 2026-04-30
chroncal freebusy --calendar Work --from 2026-04-01 --to 2026-04-30 --remote

Installation

chroncal is available through eight installation channels covering Linux, macOS, and Windows:

Method	Platforms
Install script	Linux, macOS, FreeBSD, OpenBSD
Homebrew	macOS, Linux
Go install	Any platform with Go 1.25+
mise	macOS, Linux
Nix	Linux, macOS
Scoop	Windows
AUR	Arch Linux
Build from source	Any platform with Go 1.25+

The quickest path on Linux or macOS:

curl -fsSL https://raw.githubusercontent.com/DouglasdeMoura/chroncal/master/scripts/install.sh | sh

Or with Homebrew:

brew tap douglasdemoura/tap && brew install chroncal

On Windows, the managed install path is Scoop:

scoop bucket add chroncal https://github.com/DouglasdeMoura/scoop-bucket
scoop install chroncal

Or if you use mise:

mise use -g github:DouglasdeMoura/chroncal

chroncal also has a custom app icon for launchers:

If you use Omarchy, you can add chroncal to the app menu with one command:

omarchy tui install chroncal chroncal float https://raw.githubusercontent.com/DouglasdeMoura/chroncal/master/assets/chroncal-512.png

That creates a launcher item that opens chroncal in your configured terminal. The float style opens it in a centered floating window; use tile if you want it to behave like a normal tiled window.

Data storage

The database is a single SQLite file with WAL mode enabled for concurrency. Migrations run automatically on startup. Default locations:

Linux: ~/.local/share/chroncal/chroncal.db
macOS: ~/Library/Application Support/chroncal/chroncal.db

Override with CHRONCAL_DB or the db key in config.toml. Because it is a single file, backing up or moving your calendar data is a file copy.

What is next

chroncal is at v0.3.x and MIT-licensed. The core feature set — events, todos, journals, CalDAV sync, alarms, iCal import/export, full-text search, and recurring rules — is working and tested. Todo and journal management in the TUI is the next major focus, along with .deb and .rpm packages.

If you live in the terminal and want your calendar data local, portable, and scriptable, give it a try. The repository is at github.com/DouglasdeMoura/chroncal, and issues and contributions are welcome.

Aube: A New Dawn for Node Installs

Douglas Moura — Mon, 08 Jun 2026 03:00:00 +0000

Aube (pronounced "ohb", from the French word for dawn) is a new Node.js package manager written in Rust by en.dev, the same developer behind Mise. It reads and writes your existing lockfile (pnpm-lock.yaml, package-lock.json, npm-shrinkwrap.json, yarn.lock, or bun.lock) in place, so you can try it in a project without forcing your team to switch package managers. I started using it this week, and I want to share my thoughts on the tool.

Speed

Aube starts from pnpm's isolated symlink model: package files live in a global content-addressable store, and projects link to them through an isolated node_modules layout. Aube also enables its global virtual store by default for local installs, while pnpm leaves its comparable feature off by default. The results show in the current benchmarks against a ~1400-package real-world fixture:

Scenario	aube	bun	deno	pnpm	npm	yarn
Fresh install (warm cache)	272 ms	2.00 s	1.33 s	2.34 s	7.14 s	8.86 s
Fresh install (cold cache)	7.95 s	5.78 s	8.15 s	15.87 s	9.51 s	13.19 s
`install && test` (already installed)	9 ms	41 ms	84 ms	335 ms	745 ms	1.18 s

The cold-cache number still trails Bun, but the warm-cache and repeat-command numbers are where aube pulls ahead. The install && test row is the developer loop: aube can skip install work when its install-state file is fresh, so repeated aubr test runs land in single-digit milliseconds.

Lockfile compatibility

This is the part that caught my attention. Aube does not introduce its own lockfile format unless you want it to. If your project already has pnpm-lock.yaml, aube reads and writes it back in place. Same for package-lock.json, npm-shrinkwrap.json, yarn.lock, and bun.lock. That means you can run aubr test in a pnpm project today and your teammates who use pnpm will not notice a difference.

Lockfile	Reads	Writes in place
`aube-lock.yaml`	yes	yes
`pnpm-lock.yaml` v9	yes	yes
`package-lock.json` v2/v3	yes	yes
`npm-shrinkwrap.json`	yes	yes
`yarn.lock` (v1 classic + v2+ berry)	yes	yes
`bun.lock`	yes	yes

For a new project with no lockfile, aube creates aube-lock.yaml.

`aubr` and `aubx`

aubr is shorthand for aube run. Before running a script, it checks whether node_modules is fresh for the current package.json and lockfile. If dependencies are missing or stale, it installs them first; otherwise it skips straight to the script:

aubr test
aubr build

aubx is shorthand for aube dlx. It prefers an installed local binary before fetching into a throwaway environment. Useful for one-off tools:

aubx cowsay hi

Both are multicall shims that share the same binary as aube and dispatch on argv[0]. Every flag that works on the full command also works on the shim.

Less disk usage

Like pnpm, aube keeps package files in a global content-addressable store (~/.local/share/aube/store/) and links projects to it. Three apps that depend on React, Vite, TypeScript, and Playwright share the heavy files instead of storing three full copies. Aube claims up to 90% less disk usage compared to npm's approach of copying dependencies into every project.

Security defaults

Aube ships with several supply-chain protections turned on by default:

Trust policy (trustPolicy: no-downgrade) — blocks installs of a version that carries weaker trust evidence than any earlier-published version of the same package. A trust downgrade may indicate account takeover, repository tampering, or a malicious co-maintainer.
Minimum release age — 24-hour cooldown on newly published versions by default (minimumReleaseAge: 1440). Catches typo-squat and dependency-confusion attacks that get unpublished within hours.
Default-deny lifecycle scripts — dependency lifecycle scripts (preinstall, install, postinstall) do not run unless you approve them explicitly via aube approve-builds. A suspicious-script content sniff warns about known-dangerous patterns like curl | sh, base64-decode-then-evaluate, and reads of credential files.
Optional jailed builds — when jailBuilds: true is enabled and a dependency is approved to build, aube can wrap the script with a Seatbelt profile (macOS), Landlock and seccomp (Linux), or a scrubbed environment (Windows) to deny network access and limit filesystem writes. This is included in paranoid: true, but it is not the default today.
Typosquat protection — aube add checks the package you add and the resolved transitive dependency graph against OSV for MAL-* malicious-package advisories, and prompts for confirmation when a public package has a low download count.
Block exotic transitive dependencies — rejects transitive dependencies that resolve to git+, file:, or direct tarball URLs, which skip the registry and its integrity verification.

There is a paranoid: true switch that bundles all of the strict settings at once:

# aube-workspace.yaml
paranoid: true
allowBuilds:
  esbuild: true
  sharp: true

This forces jailed builds, no-downgrade trust policy, strict release-age gating, strict store integrity, strict dependency-build review, and mandatory advisory checks.

Getting started

The recommended installation path is Mise:

mise use -g aube

It is also available via Homebrew (brew install endevco/tap/aube) and npm (npm install -g --ignore-scripts=false @endevco/aube).

Inside an existing Node.js project, just run:

aubr test

Aube will install dependencies if needed and then run the script. No migration step, no lockfile conversion.

Daily commands

aube add react          # add a dependency
aube add -D vitest      # add a dev dependency
aube remove react       # remove a dependency
aube update             # update within package.json ranges
aubr build              # run a script, auto-installing if needed
aube test               # run tests, auto-installing if needed
aubx cowsay hi          # run a one-off tool
aube install            # install only (setup, Docker, CI)
aube ci                 # clean, frozen install for CI

You can also run scripts directly:

aube dev
aube build
aube lint

If the script exists in package.json, aube treats that as aube run <script>.

Audit

Aube has a built-in audit command that uses the same advisory data source as npm audit and pnpm audit:

aube audit                  # list known CVEs at low+ severity
aube audit --audit-level high
aube audit --fix            # write package.json overrides to patched versions
aube audit --json | jq      # machine-readable for CI

When to use it

Aube is worth trying if you want faster installs without changing your team's workflow. The lockfile compatibility means you can use it locally while your CI and teammates continue with pnpm, npm, or Yarn. The security defaults are the most aggressive of any Node.js package manager I have seen, and paranoid: true adds a lifecycle-script jail when you want the stricter bundle.

The project is young (v1.x, MIT-licensed, on GitHub) but moving fast. If you are already using Mise, the install is one command away.

Protecting your Node.js project against supply-chain attacks

Douglas Moura — Sun, 17 May 2026 03:00:00 +0000

Several recent supply-chain incidents have hit widely used npm packages. The TanStack compromise, for example, affected 42 packages and 84 published versions in May 2026. A few weeks earlier, the Axios compromise published malicious axios@1.14.1 and axios@0.30.4 releases.

Many malicious releases are detected and removed within hours. Delaying dependency resolution gives the ecosystem time to catch bad versions before your project installs them. It is not a complete defense, but it is a small setting with a good payoff.

npm 11.10+, Yarn 4.10+, and pnpm 10.16+ support release-age gates. pnpm 11 also sets a 24-hour cooldown by default.

npm

npm calls the setting min-release-age, and the value is in days:

npm config set min-release-age=1 --location=project

This writes min-release-age=1 to the project's .npmrc. You can also use --location=user or --location=global to write to your user or global npm configuration.

Yarn (Berry 4.10+)

Yarn calls the setting npmMinimalAgeGate. In Yarn 4.10, use minutes:

yarn config set npmMinimalAgeGate 1440

This writes npmMinimalAgeGate: 1440 to the project's .yarnrc.yml. Add --home to write to ~/.yarnrc.yml instead.

Current Yarn versions also accept duration strings, so this is equivalent:

yarn config set npmMinimalAgeGate 1d

pnpm

pnpm calls the setting minimumReleaseAge, and the value is in minutes:

pnpm config set --location=project minimumReleaseAge 1440

This writes minimumReleaseAge: 1440 to pnpm-workspace.yaml. Use --location=global if you want to write to the global pnpm configuration instead.

If you are already on pnpm 11, this is the default. Setting it explicitly can still be useful because it documents the policy in the repository and keeps older pnpm 10.16+ installs protected.

A note for Dependabot and Renovate users

The package-manager settings above are enforced when dependencies are installed or resolved. Dependency update bots make their own decisions before that point, so configure them too.

For Dependabot, use cooldown in dependabot.yml:

cooldown:
  default-days: 1

Dependabot cooldowns apply to version updates, not security updates.

For Renovate, set minimumReleaseAge:

{
  "minimumReleaseAge": "1 day"
}

Renovate also bypasses minimumReleaseAge for security updates.

A word of caution

Keep committing your lockfile and use deterministic installs in CI, such as npm ci, pnpm install --frozen-lockfile, or yarn install --immutable. A release-age gate reduces the chance of pulling a brand-new malicious version, but it will not clean up a compromised lockfile or make an already-installed bad version safe.

Managing your development environment with Mise (and understanding shims!)

Douglas Moura — Sun, 03 May 2026 19:09:00 +0000

I have run into this scenario a lot: we start a new project with the latest version of a programming language, but still need to maintain a legacy application that uses an older version of the same language. Sometimes I am working on a project that uses the LTS version, but I want to experiment with the latest nightly release on the side. Pretty much every language has some kind of tool to handle this, like nvm, fnm, n, or volta for Node.js, pyenv for Python, rbenv for Ruby, goenv for Go, and so on. There are also polyglot solutions, which work for several languages, like ASDF and my favorite one, Mise.

The tool

Mise is a solo project by Jeff Dickey, a Dallas-based developer who maintains a bunch of open-source tools (check his website to see what he is up to). Besides managing programming language versions, Mise can set up environment variables and run project-specific tasks with the configured tool versions. You are not bound to its conventions, either: if you want to keep using the version file your project already has, like .nvmrc or .node-version for Node.js, Mise will respect it.

The inner workings

In simple terms, Mise installs the binaries for the selected programming language and shims your calls to that language.

What is a shim?
A shim is a small compatibility layer that intercepts a call, handles it directly, or redirects it somewhere else. You can think of it as a proxy.

To get a glimpse of how this works, let's implement a very basic shim to manage Node.js.

Linux and Bash

First, download Node.js' standalone binaries here. Use the .tar.xz archives. Extract them and move the extracted directories to ~/.nodejs. This directory should now look something like this:

node-v24.15.0-linux-x64
node-v25.9.0-linux-x64

This Bash example also works on macOS. The only meaningful difference is the platform suffix in the extracted Node.js directory and in the binary_path line: use darwin-arm64 on Apple Silicon Macs or darwin-x64 on Intel Macs. For example:

binary_path="$dir/node-v$version-darwin-arm64/bin/node"

Now, let's create a directory for our tests: mkdir ~/shim-example. Then, let's add a file that tells the shim which version of Node.js we want to use in that directory. Run:

echo "24.15.0" > ~/shim-example/.node-version

Finally, let's create the Bash script that will select the Node.js version we want:

#!/usr/bin/env bash

# Makes the script exit when: a command fails (-e), a variable is unset (-u), any command in a pipeline fails (-o pipefail)
set -euo pipefail

# Set the directory where you will save all the Node.js binaries you want
dir="$HOME/.nodejs"

if [ ! -f .node-version ]; then
  echo "No Node.js version defined. Please create a .node-version file and write the desired version."
  exit 1
fi

# Read the .node-version file to select the desired Node.js version
version=$(cat .node-version)

if [ -z "$version" ]; then
  echo "No Node.js version defined. Please write the desired version in .node-version."
  exit 1
fi

binary_path="$dir/node-v$version-linux-x64/bin/node"

if [ ! -f "$binary_path" ]; then
  echo "Node.js $version is not installed at $dir. Go to https://nodejs.org/en/download, download a standalone binary, and extract it into $dir."
  exit 1
fi

exec "$binary_path" "$@"

Save this Bash script as node, then move it to ~/.local/bin and make it executable:

mkdir -p ~/.local/bin
mv node ~/.local/bin/node
chmod +x ~/.local/bin/node

This directory will probably already be on your $PATH. You can check with:

printf '%s\n' "$PATH" | tr ':' '\n' | grep -Fx "$HOME/.local/bin"

If nothing is returned, you should add this directory to your $PATH. Make sure it appears before any other directory that contains a node executable. To check if everything went well, run command -v node. You should see the following output:

$ command -v node
/home/your-username/.local/bin/node

Now, run node --version inside the ~/shim-example directory. You should see v24.15.0. Change the version in .node-version to 25.9.0 (echo "25.9.0" > .node-version) and run node --version again. You should see the new Node.js version activated in that directory.

Windows and PowerShell

On Windows, download the .zip standalone binaries from the same Node.js download page. Extract them into $HOME\.nodejs. That directory should look something like this:

node-v24.15.0-win-x64
node-v25.9.0-win-x64

Create the test directory and .node-version file:

New-Item -ItemType Directory -Force -Path "$HOME\shim-example"
Set-Content -Path "$HOME\shim-example\.node-version" -Value "24.15.0"

Then create this PowerShell shim:

$ErrorActionPreference = "Stop"

$versionsDir = Join-Path $HOME ".nodejs"
$versionFile = Join-Path (Get-Location) ".node-version"

if (-not (Test-Path -LiteralPath $versionFile -PathType Leaf)) {
  Write-Error "No Node.js version defined. Please create a .node-version file and write the desired version."
  exit 1
}

$version = (Get-Content -LiteralPath $versionFile -Raw).Trim()

if ([string]::IsNullOrWhiteSpace($version)) {
  Write-Error "No Node.js version defined. Please write the desired version in .node-version."
  exit 1
}

$versionDir = Join-Path $versionsDir "node-v$version-win-x64"
$binaryPath = Join-Path $versionDir "node.exe"

if (-not (Test-Path -LiteralPath $binaryPath -PathType Leaf)) {
  Write-Error "Node.js $version is not installed at $versionsDir. Go to https://nodejs.org/en/download, download a standalone binary, and extract it into $versionsDir."
  exit 1
}

& $binaryPath @args
exit $LASTEXITCODE

Save it as node.ps1 in a directory that is on your PowerShell path. For example:

New-Item -ItemType Directory -Force -Path "$HOME\bin"
Move-Item -Path .\node.ps1 -Destination "$HOME\bin\node.ps1" -Force

If $HOME\bin is not on your path yet, add it for your user. Put it before the existing path so this shim wins over any other Node.js installation:

$userPath = [Environment]::GetEnvironmentVariable("Path", "User")
[Environment]::SetEnvironmentVariable("Path", "$HOME\bin;$userPath", "User")

Open a new PowerShell session so it picks up the updated path. Then check that PowerShell finds the shim:

Get-Command node

Finally, run node --version inside $HOME\shim-example. You should see v24.15.0. Change the version in .node-version to 25.9.0 (Set-Content -Path .\.node-version -Value "25.9.0") and run node --version again.

Mise does all of this, and a little more, using Rust. This example should still give you a pretty good idea of how it works.

Installing and configuring Mise

There is a myriad of ways to install Mise, so I recommend going directly to its documentation. After installing and configuring Mise, install the tools you need. Personally, I do not use the Mise configuration file (mise.toml) in the Node.js projects I work on, because some people on the team use different tooling. Instead, I add the Node.js version to .node-version, which is supported by a large number of similar tools.

Introducing Alucard: a light theme for Omarchy

Douglas Moura — Sun, 26 Apr 2026 13:28:20 +0000

Since January, I've been using my own light theme for Omarchy (do you use Linux and don't know Omarchy yet? Go check it out!) and I forgot to make an official announcement! So, yes, this late post is an attempt to rectify this mistake.

Alucard: a light theme for Omarchy (and the arch-enemy of Dracula)

I'm a die hard fan of the Dracula theme and I have been using it for years. And, as you might have guessed, I've been using everything I could with a dark theme. But, I have moved to a new house, which is super illuminated by the sun throughout the day with massive windows and, using dark themes with so much natural light proved to be a difficult task. Omarchy (my Linux distro of choice) comes very well served of beautiful themes and I started to use either Flexoki Light or Catppuccin Latte during the day. Yet, neither were quite my taste and I knew there were already a light version of the Dracula theme called Alucard that was offered by their Pro package. When I went to their website to check it out, I found out a quite complete specification for the Dracula and the Alucard theme, so, I did what any developer who loves open source do: I scratched my own itch, I mean, I started working on the Alucard theme for Omarchy and I have been using it everyday since January.

The road to get everything working beautifully

When I started digging into the specification and building the theme, I found out a lot of applications (Alacritty, btop, Chromium, Ghostty, and Kitty) didn't had official Alucard themes, so I started building them myself (I yet have to create single repositories for them and open a PR to the Dracula team, I'll be doing it shortly). It took a few iterations for me to get satisfied with the color combinations, but everything worked beautifully.

The wallpapers

Currenttly, the theme is distributed with three wallpapers: Dracula Waves, Dracula Mountain, and Dracula Galaxy, all of which were taken from the official Dracula wallpapers repository. I simply love the Dracula Waves walppaper and that's why it's the first choice when you install the theme.

The repository

All the code is available at douglasdemoura/omarchy-alucard-theme. Feel free to send your feedback and contributions to make it event better.

The installation

If you are using Omarchy, you can install the Alucard theme with the command below:

omarchy-theme-install https://github.com/douglasdemoura/omarchy-alucard-theme

[Boost]

Douglas Moura — Fri, 05 Dec 2025 23:48:46 +0000

Sam

Dec 5 '25

How I made BeeThreads and what doest it solve

#showdev #ai #node #performance

3 min read

Validate your environment variables with Zod

Douglas Moura — Fri, 16 Aug 2024 03:00:00 +0000

Zod is the most famous validation library in the TypeScript ecosystem. With Zod, you create a schema and validate your data according to the schema. Observe the schema below:

import { z } from 'zod'

const UserSchema = z.object({
  name: z.string().min(1),
  age: z.number({ coerce: true }).min(18),
  email: z.string().email(),
})

This schema can be used to validate an object as follows:

const data = {
  name: 'John Doe',
  age: 18,
  email: 'john@example.com',
}

// If there is a validation error, it throws an error
const validatedData = UserSchema.parse(data)

// If there is a validation error, it returns an error object for you to handle later
const safeValidatedData = UserSchema.safeParse(data)
// => { success: false; error: ZodError }
// => { success: true; data: 'billie' }

Zod is capable of performing various types of validations on your data, so be sure to read the documentation for more details.

Validating Environment Variables

We can use Zod to validate the values present in process.env and even process them before using the environment variables in our application. Usually, I like to create an environment.ts file, as in the example below:

import { z } from 'zod'

const environmentSchema = z.object({
  // Define the possible values for NODE_ENV, always leaving a default value:
  NODE_ENV: z.enum(['test', 'development', 'production']).default('production'),
  // Environment variables are always defined as strings. Here, convert the string to a number and set a default value:
  PORT: z.number({ coerce: true }).default(3000),
})

export const env = environmentSchema.parse(process.env)

Then, just import the variable and use it throughout my application:

import Fastify from 'fastify'
import { env } from './environment.js'

const app = Fastify({ logger: true })
app.listen({ port: env.PORT }, (err) => {
  if (err) {
    app.log.error(err)
    process.exit(1)
  }
})

Using TypeScript in Node.js projects

Douglas Moura — Mon, 08 Jul 2024 09:46:58 +0000

TypeScript is tremendously helpful while developing Node.js applications. Let's see how to configure it for a seamless development experience.

Setting up TypeScript

First, we need to install TypeScript. We can do this by running the following command:

npm i -D typescript

Next, we need to create a tsconfig.json file in the root of our project. This file will contain the TypeScript configuration for our project. Here is an example of a tsconfig.json file that I picked from Total TypeScript and added a few more things (read the code and pay attention to the comments):

{
  "compilerOptions": {
    /* Base Options: */
    "esModuleInterop": true,
    "skipLibCheck": true,
    "target": "es2022",
    "allowJs": true,
    "resolveJsonModule": true,
    "moduleDetection": "force",
    "isolatedModules": true,
    "verbatimModuleSyntax": true,

    /* Setting ~ as the alias for the src/ directory */
    "baseUrl": ".",
    "paths": {
      "~/*": ["src/*"]
    },

    /* Strictness */
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,

    /* If transpiling with TypeScript: */
    "module": "NodeNext",
    "outDir": "dist",
    "sourceMap": true,

    /* AND if you're building for a library: */
    "declaration": true,

    /* AND if you're building for a library in a monorepo: */
    "composite": true,
    "declarationMap": true,

    /* If NOT transpiling with TypeScript: */
    "module": "preserve",
    "noEmit": true,

    /* If your code runs in the DOM: */
    "lib": ["es2022", "dom", "dom.iterable"],

    /* If your code doesn't run in the DOM: */
    "lib": ["es2022"],
  },
  /* I'm considering all your code is in src/ */
  "include": ["src/**/*.ts"]
}

Setting up the build script

Next, we need to set up a build script that will compile our TypeScript code to JavaScript. First, install tsc-alias to handle the aliases we defined in the tsconfig.json file:

npm i -D tsc-alias

Then, you can add the build script by adding the following script to our package.json file:

{
  "scripts": {
    "build": "tsc && tsc-alias"
  }
}

Setting up the development script

Next, we need to set up a development script that will watch for changes in our TypeScript files and recompile them. Personally, I like to use tsx, as it provides a much faster development experience compared to the built-in TypeScript watcher or ts-node. First, install tsx:

npm i -D tsx

Then, you can add the dev script (in order to start the project in development mode) by adding the following script to your package.json file:

{
  "scripts": {
    "build": "tsc && tsc-alias",
    "dev": "node --import=tsx --watch ./src/index.ts"
  }
}

Yes, you won't get typechecks while developing using tsx, but you can run npm run build for that or add a new typecheck scripts to your package.json, and run it whenever you want to check for type errors:

{
  "scripts": {
    "build": "tsc && tsc-alias",
    "dev": "node --import=tsx --watch ./src/index.ts",
    "typecheck": "tsc --noEmit"
  }
}

The Powerful Programmer

Douglas Moura — Tue, 23 Jan 2024 13:31:11 +0000

Estimating, implementing, and deploying software rapidly is a characteristic of powerful programmers, as Kent Beck mentions in his book Extreme Programming Explained. In this article, I will explore these three points, inserting my own opinions on each one.

Estimation

Estimating a software project is difficult, and there are various different techniques on how to estimate a software project. You can create a method, through your own experience, learn the method used by other companies but, you must pay attention that the central point is that you have a good idea of how much time the project will take. Projects have a beginning, middle, and end. Learn to estimate your work.

Implementation

For me, particularly, implementing is the most fun part of the project. And as with any job, we have to be pragmatic in the choice of language and tools. Being pragmatic in the choice does not necessarily mean using the same as everyone else, because, often, some tools continue to be strong in the market due to pure inertia. Express is a good example of this. Besides there being many better options with better support (like Fastify), many teams still start new projects with Express, even if it is not being maintained regularly, does not handle Promise rejections, etc.

Besides the issue of tool choice, it is necessary that you master the technology stack of your project, being able to implement the best solutions in the shortest possible time. At the tip of your tongue, you have to know a good pattern to apply in the project, a good backend framework, a good frontend framework or even a good full-stack framework. And the experience of development cannot be left out. For the implementation to be fast, the understanding of the project must be easy, its documentation adequate, and its tests need to validate the intention flows of the user who will use the system.

Deployment

Today, can you build an entire project and put it into production, by yourself? And I'm not talking about uploading your project to a completely managed platform, like Vercel, but rather, about taking a Linux machine, installing the necessary tools, and exposing your application to the web. And no, this is not any kind of purism. If you are not a startup that can burn a few million reais per year, without worrying about the cost of your infrastructure, you should, at least, know how to start your application and keep it active between server restarts (preferably using containers), put it behind a reverse proxy (like NGINX or Caddy), configure a firewall, and make a backup of the database in three different places. You can still bring up multiple instances of your application and use the same proxy tool as a load balancer to distribute your application's access to the different instances that are running.

Generating MD5 hashes on Node.js

Douglas Moura — Tue, 23 Jan 2024 13:28:34 +0000

You can create hashes in Node.js without the need to install any external library. Usually, I create the following utility function in the projects I work on:

/**
 * Hashes a string using md5
 *
 * @param {string} str
 * @returns {string}
 */
export const md5 = (str) => createHash('md5').update(str).digest('hex')

And I use it to replace the md5 library whenever I come across it.

Note that you can create hashes for any algorithm supported by the OpenSSL version on your platform. On Linux and Mac, you can see which algorithms are available with the command openssl list -digest-algorithms.

Finding the greatest common divisor in TypeScript

Douglas Moura — Sat, 13 Jan 2024 04:00:00 +0000

First described in the classic geometry book Elements, by the ancient Greek mathematician Euclid (ca. 300 BC, at the book VII, proposition 2), the method of finding de greatest common divisor between the positive numbers a and b, being a > b consists on the knowledge that the common divisors of a and b are the same of a - b and b. Therefore, we can find this greatest common divisor by replacing the largest number (a) by the different between the two numbers (a - b), repeatedly, until the two numbers are equal. In TypeScript, we can do that like this:

const gcd = (a: number, b: number): number => {
  // When `a` is equal to `b`, return the result
  if (a === b) {
    return a
  }

  // When `a` is bigger than b, calculate the the GCD again
  // with the new `a` being `a - b`.
  if (a > b) {
    return gcd(a - b, b)
  }

  // If the new `b` is bigger than `a`,
  // subtract a from it.
  return gcd(a, b - a)
}

This method can be very slow if the difference between a and b is too large. Thankfully, there's another method to find the greatest common divisor between two numbers, that can be described as follows:

In order to find the greatest common divisor between a and b, being a > b, perform the division between the two numbers. This operation will give a quotient and a remainder (that we will call q and r, respectively). Thus, a can be described as a = q × b + r;
If r is equal to 0, we stop, because we found that the greatest common divisor of a and b is b. Otherwise, we go back to step 1, making b the new a and r will be the new b.

Now, we can start with the implementation of the algorithm above:

const gcd = (a: number, b: number): number => {
  // First, we take the remainder between the division of a and b:
  const r = a % b

  // If the remainder is equal to zero, it means that we already found the
  // greatest common divisor, therefore, we return b:
  if (r === 0) {
    return b
  }

  // If the remainder is not equal to 0, we call the function again
  // with the new values for a and b:
  return gcd(b, a % b)
}

The implementation is very straightforward and can be read exactly as is described in steps 1 and 2. We can make the function simpler, by checking, directly, if b is equal to zero and only doing the remainder operation afterwards. Therefore, if the function receive a b that is equal to zero, we will know that a is the greatest common divisor:

const gcd = (a: number, b: number): number => {
  if (b === 0) {
    return a
  }

  return gcd(b, a % b)
}

This variant is called Euclidean algorithm (in contrast of the first one, which is the Euclid's algorithm) and it significantly faster than the first implementation.

Alternative implementations

We can also take a different approach. Instead of calling our gcd function recursively, we can implement our function using a while loop (analogous to our first implementation above):

const gcd = (a: number, b: number): number => {
  // Run this loop while a is different of b
  while (a !== b) {
    if (a > b) {
      // Subtracts b from a while a is bigger than b
      a = a - b
      // Go to the next loop
      continue
    }
    // Subtracts a from b when a <= b
    b = b - a
  }
  // Returns the greatest common divisor between a and b
  return a
}

And this is another way (analogous to our second implementation above):

const gcd = (a: number, b: number): number => {
  // Run this loop while `b` is different from 0
  while (b !== 0) {
    // Save the new value for a in a temporary variable
    const newA = b
    // Set b to the modulo of a and b (the remainder of the division between a and b)
    b = a % b
    // Set a to its new value before the next loop
    a = newA
  }

  // Now that b is equal to 0, we know that a is the greatest common divisor
  return a
}

Finding the greatest common between three or more numbers

The greatest of three or more numbers is equal the product of the prime factors common to all the numbers (we will explore more of that in a future article), but, you can also calculate the greatest common divisor between pairs of this list of numbers with the same functions we have showed already. So, let's refactor our gcd function to receive multiple parameters:

const gcd = (...numbers: number[]): number => {
  const calculateGcd = (a: number, b: number): number => {
    if (b === 0) {
      return a
    }

    return calculateGcd(b, a % b)
  };

  return (
    numbers
      // Just to be sure, sort numbers in descendant order:
      .sort((a, b) => b - a)
      // Call `calculateGcd` for each pair in the numbers array:
      .reduce((a, b) => calculateGcd(a, b))
  )
}

Validating our input

Let's guarantee that our functions should always receive, at least, two numbers and that all numbers must not be negative:

const gcd = (...numbers: number[]): number => {
  if (numbers.length < 2) {
    throw new Error("You must pass, at least, 2 numbers")
  }

  if (numbers.some((number) => number < 0)) {
    throw new Error("The numbers must be >= 0")
  }

  const calculateGcd = (a: number, b: number): number => {
    if (b === 0) {
      return a
    }

    return calculateGcd(b, a % b);
  };

  return (
    numbers
      // Just to be sure, sort numbers in descendant order:
      .sort((a, b) => b - a)
      // Call `calculateGcd` for each pair in the numbers array:
      .reduce((a, b) => calculateGcd(a, b))
  )
}

Understanding Tail Call Optimization With JavaScript

Douglas Moura — Wed, 25 Oct 2023 10:00:00 +0000

Consider the following function that calculates the factorial of a number:

const factorial = (n) => {
  let result = 1

  while (n > 1) {
    result *= n
    n--
  }

  return result
}

The function above was implemented iteratively, that is, it uses a loop to calculate the factorial of a number. However, it is possible to implement the same function recursively (that is, a function that references itself):

const factorial = (n) => {
  if (n === 0) return 1

  return n * factorial(n - 1)
}

The result of both functions is the same, however, the iterative function is much more efficient (in JavaScript) than the recursive function. In addition, if we try to calculate the factorial of a very large number, we encounter the error RangeError: Maximum call stack size exceeded. Let's understand why this happens and how we can improve the recursive function.

Call Stack

A call stack is a data structure that stores information about a program's functions. When a function is called, it is added to the execution stack, as well as all the functions it calls. When a function returns, it is removed from the execution stack. Each function added to the stack is called a stack frame.

In order to understand what is happening, let's try to represent, graphically, how the calculation of the factorial of 6 is done with the iterative function:

Now, compare it with the substitution model for calculating the factorial of 6 using the recursive function:

Note that, in the iterative function, the arrow shape is linear and we can see the state of each variable at each step. In addition, at each iteration of our loop, a calculation is performed and the variables stored in memory are updated. In the recursive function, the arrow shape is exponential and we cannot see the state of all variables in the first half of the processing. In addition, each time the function is executed, more memory needs to be used to store the resulting values of each execution.

But what does this mean? In order for JavaScript to calculate the factorial of 6 using the iterative function, the while condition is added to the stack, where its calculation is performed, the result variable is updated, and then the executed code block of the while is removed from the stack. This is done until the while condition is false, that is, until the value of n is less than or equal to 1.

In the recursive function, each call to the factorial function is added to the stack as many times as necessary until the if condition is false, that is, until the value of n is less than or equal to 1. This means that, to calculate the factorial of 6, the factorial function is added to the stack 6 times before being executed. And that's why, when we try to calculate the factorial of a large number (100,000, for example), we encounter the error RangeError: Maximum call stack size exceeded: there is not enough space in the stack to store all the calls to the factorial function.

Introducing Tail Call Optimization

As defined by Dr. Axel Rauschmayer:

[...] whenever the last thing a function does is call another function, then this last function does not need to return to its caller. As a consequence, no information needs to be stored on the call stack and the function call is more like a goto (a jump). This type of call is called a tail call; not increasing the stack is called tail call optimization (TCO).

Now, we have discovered that our factorial calculation function is not tail recursive. But how can we make it tail recursive? With the help of another function:

const factorial = (n) => {
  return factorialHelper(n, 1)
}

const factorialHelper = (x, accumulator) => {
  if (x <= 1) {
    return accumulator
  }

  return factorialHelper(x - 1, x * accumulator)
}

Now, our function is tail recursive: the last thing it does is call a function (and not calculate an expression, as in the first implementation). Now, let's see the substitution model for calculating the factorial of 6 with our new factorial function:

The performance is superior to our first implementation, although it still doesn't beat the performance of the iterative function. However, we still encounter the error RangeError: Maximum call stack size exceeded. But why does this happen? Because, despite our function being tail recursive, current versions of Node.js and browsers (with the exception of Safari) do not implement Tail Call Optimization (despite its inclusion in the EcmaScript specification since 2015).

But how will we solve this problem? With the help of another function, of course! For that, we will rely on the Trampoline pattern:

const trampoline = (fn) => {
  while (typeof fn === 'function') {
    fn = fn()
  }

  return result
}

Our trampoline function consists of a loop that invokes a function that wraps another function (what we call a thunk) until there are no more functions to execute. Let's see how the implementation of our factorial function would look like with the Trampoline pattern:

const trampoline = (fn) => {
  while (typeof fn === 'function') {
    fn = fn()
  }

  return fn
}

const factorialHelper = (x, accumulator) => {
  if (x <= 1) {
    return accumulator
  }

  // Now, a function returns another function
  return () => factorialHelper(x - 1, x * accumulator)
}

const factorial = (n) => {
  return trampoline(factorialHelper(n, 1))
}

And now, we can call our factorial function with a large number, without encountering the error RangeError: Maximum call stack size exceeded. Of course, depending on the factorial we want to calculate, we will encounter an Infinity, as it is a very large number (a number greater than Number.MAX_SAFE_INTEGER: 253 - ¹). In this case, we can use BigInt:

const trampoline = (fn) => {
  while (typeof fn === 'function') {
    fn = fn()
  }

  return fn
}

const factorialHelper = (x, accumulator) => {
  if (x <= 1) {
    return accumulator
  }

  return () => factorialHelper(x - 1n, x * accumulator)
}

const factorial = (n) => {
  // Converting values to BigInt
  //-------------------------------\/----------\/
  return trampoline(factorialHelper(BigInt(n), 1n))
}

Typing our function

And finally, let's add the necessary types to our factorial function:

type Thunk = bigint | (() => Thunk)

const trampoline = (fn: Thunk) => {
  while (typeof fn === 'function') {
    fn = fn()
  }

  return fn
}

const factorialHelper = (x: bigint, accumulator: bigint): Thunk => {
  if (x <= 1) {
    return accumulator
  }

  return () => factorialHelper(x - 1n, x * accumulator)
}

const factorial = (n: number) => {
  return trampoline(factorialHelper(BigInt(n), 1n))
}