Improving Blog-Writing Workflow with VSCode's DevContainer and Astro

In pursuit of an efficient development workflow for my personal blog, ainoya.dev, I experimented with leveraging the capabilities of VSCode’s DevContainer feature. This post details the journey of enhancing my blog development process, primarily using Astro, by integrating DevContainer into my workflow.

Introduction to DevContainer

VSCode’s DevContainer offers a seamless way to containerize the development environment. This means consistent, isolated, and replicable development settings for any project. Utilizing this for my blog, written using Astro, presented an opportunity to streamline the setup and reduce startup times for the development server.

Setting Up DevContainer for Astro

The .devcontainer/devcontainer.json file is the heart of configuring the DevContainer environment. I tailored the settings to cater to my Astro blog’s needs, as illustrated below:

{
    "name": "Node.js & TypeScript",
    "image": "mcr.microsoft.com/devcontainers/typescript-node:1-20-bullseye",
    "forwardPorts": [4321],
    "portsAttributes": {
        "4321": {
            "label": "Astro",
            "onAutoForward": "openBrowser"
        }
    },
    "postCreateCommand": "pnpm config set store-dir /home/node/.local/share/pnpm/store && pnpm install --frozen-lockfile",
    "postStartCommand": "nohup bash -c 'pnpm run dev &'",
    "remoteUser": "node",
    "customizations": {
        "vscode": {
            "extensions": ["astro-build.astro-vscode"]
        }
    }
}

This configuration automatically starts the Astro development server in the background upon container startup, significantly reducing the waiting time.

Resolving pnpm install Issues on macOS and devcontainer

The primary issue arose when running pnpm install within the DevContainer on macOS. The error message was ERR_PNPM_LINKING_FAILED, indicating a failure in the linking process during installation. This problem seemed unique to the macOS environment, particularly when used in conjunction with Docker.

Understanding the Cause

The root cause of this issue is tied to the way Docker interacts with the macOS file system. More specifically, it’s related to how pnpm uses hard links to optimize dependency installations. Hard links work differently in Docker’s virtualized file system on macOS compared to Linux containers, leading to the error during the copying of files. (ref)

Implementing a Solution

To address this, I modified the pnpm configuration to change the storage directory of the package store. This was achieved by adding a specific command in the postCreateCommand section of the DevContainer configuration:

"postCreateCommand": "pnpm config set store-dir /home/node/.local/share/pnpm/store && pnpm install --frozen-lockfile",

After changing the pnpm store directory, it was essential to add the new store directory, .pnpm-store, to the .gitignore file.