chromium-dev-toolkit (crdev)

A VS Code extension for developing any Chromium checkout on Windows, macOS and Linux. It works with zero config (gn + autoninja + the standard chrome executables) and needs no other VS Code extension for debugging. A project only overrides what differs, usually the build command.

• Build configurations: each one is an out dir with an optional build command override (default autoninja), executable and symbol paths, picked in the status bar or the panel.
  • Undeclared out dirs appear automatically.
  • Each configuration generates compile_commands.json and applies it to clangd: clangd.path, --compile-commands-dir, then a clangd restart.
• Launch profiles and flag toggles: remote debugging (CDP), UI DevTools, logging, WebUI from disk, features and switches from a searchable catalog of the checkout, and per-process auto-attach gates.
• Debugging on every OS:
  • lldb-dap with Chromium's tools/lldb helpers, through one shared server per window, so child attaches take about a second instead of 90.
  • Renderer, GPU and utility processes are attached automatically.
  • Breakpoint presets and named breakpoint sets.
  • Crash dumps open in the debugger.
• Chrome UI debugging in VS Code, native and WebUI: it lives on the panel's Chrome UI page, and all its commands start with crdev: Chrome UI:. Build & Launch for Chrome UI (or the Chrome UI (native + WebUI) profile) sets everything below up in one go.
  • Native UI (Views): C++ in the crdev session, plus Inspect in VS Code, which opens UI DevTools (the Views tree, properties and highlight) in an editor tab.
  • WebUI: Debug WebUI JS attaches VS Code's own JavaScript debugger to chrome:// pages and to WebUI in the browser UI (omnibox popup, side panels, tab search), next to the C++ sessions.
  • DevTools… opens the browser's DevTools for any of these targets in a VS Code tab.
  • Breakpoints in the checkout's .ts files need the gn arg enable_webui_inline_sourcemaps = true.
• Live tools: CDP page watches and live UMA histograms, a filtered browser-log tail with click-to-source, a crash inbox with analysis and live dump capture, and a gtest runner (find, build, run, debug, re-run failed).
• Toolkit panel: a webview in its own activity-bar view, organized in pages so nothing hides at the bottom of a long scroll: Launch · Debug · Flags · Watch · Logs · Crashes · Tests · Doctor.
• Config help:
  • A JSON schema gives IntelliSense in crdev.jsonc and crdev.team.jsonc.
  • crdev: Generate Annotated Config writes every option, commented out, with descriptions and defaults.
  • Configs from a repo only run commands in a trusted workspace.

Status: public beta.

• Design
• How to run and test
• Panel plugin contract
• Windows spike results

Releasing

The Release workflow uses the same flow as better-review: type-check and unit-test, build a universal VSIX, retain the VSIX and its SHA-256 checksum as workflow artifacts, create a GitHub release, then publish the same package on the VS Code Marketplace as cgqaq.crdev.

1. Update version in package.json and package-lock.json and add a ## [x.y.z] section to CHANGELOG.md.
2. Preview the notes with npm run --silent release:notes -- x.y.z and push the version changes.
3. Push the matching vX.Y.Z tag. For the initial version, use v0.1.0.

The tag must match the package version. Versions with a hyphen, such as 0.1.0-beta.1, become GitHub prereleases and skip Marketplace publishing. Release notes come from the matching changelog section, preserving Markdown formatting and joining wrapped paragraph lines; a missing section uses GitHub's generated notes. Rerunning a release skips GitHub releases and Marketplace versions that already exist.

Run the workflow from the Actions tab with dry_run enabled (the default) to run checks and keep the VSIX and checksum without publishing. Disable it to release the version at the selected ref.

Marketplace publishing uses Trusted Publishing with GitHub OIDC. In the cgqaq publisher's Trusted Publishing settings, create a policy with repository owner CGQAQ, repository chromium-dev-toolkit, workflow release.yml, and no environment. Run the workflow with check_publishing enabled to verify the policy; this only signs in and publishes nothing. For a private repository, the first successful sign-in must occur within 48 hours of creating the policy.