Dev Container Features

Small, dependable Dev Container Features from raine-works.

Add one or more features to your devcontainer.json:

{
    "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
    "features": {
        "ghcr.io/raine-works/devcontainer-features/bun:1": { "version": "1.2.0" },
        "ghcr.io/raine-works/devcontainer-features/deno:1": {},
        "ghcr.io/raine-works/devcontainer-features/node:1": { "pnpm": "10.4.1", "yarn": "latest", "bun": "latest" }
    }
}

Omit version (or set it to latest) to get the newest release. The :1 tag follows the feature's major version, so you get compatible updates without breaking changes.

Requirements: a Debian/Ubuntu based image. Each feature's README documents its options.

src/<feature>/devcontainer-feature.json   Feature metadata and options
src/<feature>/install.sh                  Install script (runs as root at build time)
src/<feature>/NOTES.md                    Hand-written notes appended to the generated README
test/<feature>/scenarios.json             Scenario tests (pinned versions, base images)
test/<feature>/*.sh                       Assertions run inside each scenario
.github/workflows/                        Validate, test, and release pipelines

Per-feature README.md files are generated from devcontainer-feature.json on release. Edit NOTES.md instead of the README.

Open the repo in its dev container (it ships the devcontainer CLI), then:

# Autogenerated tests for one feature against a base image
devcontainer features test --skip-scenarios -f bun -i ubuntu:latest .

# Scenario tests (pinned versions)
devcontainer features test -f bun --skip-autogenerated --skip-duplicated .

1. Bump version in the feature's devcontainer-feature.json.
2. Merge to master.

The Release dev container features & Generate Documentation workflow runs automatically on pushes to master that touch src/. It publishes only features whose version is not yet in GHCR and opens a PR with regenerated docs. It can also be started manually from the Actions tab. Merging that docs PR triggers one more run, which finds nothing to publish.

The release workflow uses the built-in GITHUB_TOKEN; no secrets are required. One-time setup: enable Settings > Actions > General > Allow GitHub Actions to create and approve pull requests, otherwise the docs PR step fails. PRs opened this way do not trigger CI, which is fine for generated READMEs.

If these features save you time, a coffee is appreciated:

MIT