devcontainer-cli: Add version 0.87.0

[FHYQ-Dong]

• References the official CLI from https://github.com/devcontainers/cli
• Uses npm registry as download source
• Depends on nodejs runtime (not bundled)
• Entry point: package/devcontainer.js via node shim

Closes #8319

• Use conventional PR title: <manifest-name[@version]|chore>: <general summary of the pull request>
• I have read the Contributing Guide

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 2a27f3ad-61b2-4750-9a70-bf2149294862

📥 Commits

Reviewing files that changed from the base of the PR and between 38df47b and 358d7aa.

📒 Files selected for processing (1)

• bucket/devcontainer.json

---

Summary by CodeRabbit

• New Features
  • Added a package manifest for installing the devcontainers CLI through the bucket.
  • Configured the CLI executable, package metadata, and automated version update checks.

Walkthrough

Changes

Devcontainer CLI

Layer / File(s)	Summary
Package installation manifest bucket/devcontainer.json	Adds metadata for version 0.87.0, the Node.js dependency, pinned CLI archive and hash, extraction directory, executable mapping, and automated update settings.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is concise, specific, and matches the added devcontainer-cli 0.87.0 manifest.
Description check	✅ Passed	The PR description includes a summary, issue reference, and required checklist items.
Linked Issues check	✅ Passed	The manifest satisfies the request by adding devcontainer-cli 0.87.0 with npm download, nodejs dependency, and standard entrypoint.
Out of Scope Changes check	✅ Passed	The changes appear limited to the requested devcontainer-cli manifest and related metadata.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[z-Fng]

#6952 (comment)

It requires a Node.js runtime, please install it with package manager of NPM ecosystem.

I would advise against wrapping packages installed through npm, pacman, or pip into a Scoop manifest.

[FHYQ-Dong]

I understand the concern about wrapping npm packages, but I think this case is different from a typical npm install -g wrapper for a few reasons:

1. The official distribution IS self-contained, not npm-first.

The project's own install script (https://github.com/devcontainers/cli/blob/main/scripts/install.sh) downloads and bundles a specific Node.js runtime alongside the CLI. It never asks the user to npm install anything. The npm registry is used as a download mirror for the tarball, not as a package manager — the CLI tarball is fetched via HTTPS, extracted, and run with the bundled Node.js, exactly like any other self-contained tool. There's no npm install, no node_modules, no dependency resolution at install time.

2. The manifest is a self-contained tool, not an npm wrapper.

The manifest downloads two things: a Node.js runtime zip and the CLI tarball. It extracts them side by side and creates a thin .cmd launcher. The user never touches npm, never sees a package.json, and doesn't need Node.js pre-installed. This is functionally identical to how many Electron-based or runtime-bundled tools work in the Main bucket — the runtime is just a payload.

3. There are precedents in Main bucket for tools that bundle their own runtime.

Several Main bucket manifests ship tools that include their own runtime or are downloaded from language-specific registries as pre-built archives — the key distinction is whether the manifest delegates to a foreign package manager at install time vs. uses a registry URL as a download source. This manifest does the latter.

What I'm proposing:

The pre_install script is minimal (2 lines): rename the extracted Node.js directory, and write a 1-line .cmd launcher. No npm, no npm install, no post-install dependency fetching. The tool is fully self-contained after scoop install.

Would this be acceptable for Main, given that the tool's own distribution strategy is self-contained rather than npm-native?

[z-Fng]

The manifest downloads two things: a Node.js runtime zip and the CLI tarball. It extracts them side by side and creates a thin .cmd launcher. The user never touches npm, never sees a package.json, and doesn't need Node.js pre-installed. This is functionally identical to how many Electron-based or runtime-bundled tools work in the Main bucket — the runtime is just a payload.

Most npm packages can do this as well, like Gemini-CLI.

Would this be acceptable for Main, given that the tool's own distribution strategy is self-contained rather than npm-native?

Scoop does not offer any clear advantages for managing npm or Python packages. It is usually better to use their dedicated package managers instead. My personal advice is to avoid using Scoop as a universal replacement for all tools.

Furthermore, our community is not very active at the moment. Adding a package to the official bucket that is installed via npm would likely lead to more similar requests, which would increase our maintenance overhead.

If you still insist on installing it via Scoop, please use a community-maintained bucket or set up your own personal bucket for it.

[FHYQ-Dong]

Ok, thanks for your reply. I'll reconsider my demands.