GO Domain Driven Design Scaffold

Generate a Go Domain Driven Design project layout from inside VS Code.

The extension is a wrapper around the scaffold CLI: it does not carry its own copy of the templates. That is deliberate — the templates live in exactly one place (embedded in the CLI binary), so the editor and the command line can never generate different projects.

Requirements

The scaffold CLI:

go install github.com/Allan-Nava/Go-DDD-Scaffold@latest

The extension looks for it on the PATH and then in the Go bin directories ($GOBIN, $GOPATH/bin, ~/go/bin) — that last part matters because a GUI editor does not read your shell profile, so a CLI that works in the terminal can still look missing from the editor. go install names the binary after the module (Go-DDD-Scaffold), so both that name and scaffold are recognised.

If it is not found, the extension offers to run the go install above in a terminal.

A CLI left over from before the extension was rewritten is rejected rather than used: that build ignores the folder you pick and writes next to its own executable. Its version number cannot be trusted for this (it was hardcoded to v1.0.1), so the check probes for the init --force flag. If you see "the scaffold CLI found on this machine is too old", run the go install again.

Usage

• Command palette: Go DDD: New Scaffold Project
• Explorer: right-click a folder → New Scaffold Project

The project is generated in the folder you pick (the right-clicked one, the workspace folder, or one chosen from a dialog).

If the folder is not empty you are asked what to do:

Nothing is ever overwritten without that explicit answer.

Then, in the generated project:

go mod tidy
make run                        # listens on :8080
curl localhost:8080/health      # 200

Extension Settings

Output

Every run appends the CLI's per-file output to the Go DDD Scaffold output channel, so a generation can be inspected after the notification is gone.

Releasing

Bump version in package.json and commit. The next repository tag publishes it.

# 1. bump "version" in package.json, commit
# 2. push any tag — the version decides, not the tag
git push --tags

vscode-publish.yml asks the public gallery whether that version is already online and only publishes when it is not, so the repository can carry a tag per commit without pushing a new marketplace version every time. Marketplace versions are immutable, so this also keeps a re-run from failing.

The publish steps are skipped — not failed — when the VSCE_PAT / OVSX_PAT secrets are absent.

Known limitations

• Publishing needs the VSCE_PAT repository secret (and OVSX_PAT for Open VSX); without them the workflow packages the .vsix as a build artifact and skips the upload. See the repository backlog.
• There are no integration tests running in a real editor host: the tested part is the CLI wrapper (binary discovery, argv, output parsing), which is where the logic lives.

Development

npm install
npm run compile   # tsc, strict
npm run lint      # eslint
npm test          # unit tests, no VS Code host needed
npm run webpack   # dev bundle into dist/

Release Notes

See CHANGELOG.md.