Experiments with go new: templates for new modules

intro.md

Research go new

Release ⋅ Discussion

Since golang.org/x/tools@v0.11.1, it provides an experimental command that may become go new. I have some related issues for the context of that command

• octomation/go-module#106
• octomation/go-module#145
• octomation/maintainer#10, legacy
• octomation/maintainer#135
• octomation/maintainer#153

And have task-specific templates

• https://github.com/octomation/go-module, simple module
• https://github.com/octomation/go-tool, cli-tool
• https://github.com/octomation/go-service, microservice
• https://github.com/octomation/app, full-stack app (someday)

Testing it

Prerequisites

alias run=./Taskfile

if ! command -v gonew >/dev/null; then
  go install golang.org/x/tools/cmd/gonew@latest
fi
if ! command -v gh >/dev/null; then
  go install github.com/cli/cli/v2/cmd/gh@latest
fi

export GITHUB_TOKEN=secret
gh auth status
# Token scopes: admin:org, delete_repo, repo, user, workflow

User story: quick start for experiments

I want to start with a predefined environment setup and write a prototype quickly.

gonew go.octolab.org/template/module@v1.0.0 my.new/module
cd ./module && make test

# prototyping

make test

It's useful if I want to develop something locally. But, if I need to maintain and distribute the module, I have to do something like this

git init
git commit -am 'start from template'
gh repo create module --source $(pwd) --private --push

So, how does it look without go new?

gh repo create module --template octomation/go-module --private --clone
cd ./module && make test

run init my.new/module && make test
# prototyping

make test

From my perspective:

• pros and cons for users
  • pros: go new is quicker to start
  • pros: go new will be the "native way"
  • pros: go new allows renaming a module instantly
  • cons: work with vcs is delayed
  • cons: ci/cd could be broken, e.g., if a template is GitHub-specific, and a target repository is GitLab-or-Bitbucket-specific
• pros and cons for maintainers
  • pros: nothing to do an extraordinary, similar approach
  • cons: broken relation between a template and a project based on it, e.g., GitHub templates system provides the information "generated from ..."

User story: workspace setup

I want to add a new module to the current multi-module workspace.

See. Soon...

User story: complex template with post-creation scripts

I want to create and integrate a new service into a company's infrastructure without considering its complexity.

Neither maintainer nor go new don't support the case yet. Leave it for future review.

Stress-test

mkdir -p /tmp/gonew
rm -rf /tmp/gonew/*

pushd /tmp/gonew >/dev/null || exit 1
trap 'popd >/dev/null || exit 1' EXIT

templates=(
  'go.octolab.org/template/module@v1.0.0 => my.new/module'
  'go.octolab.org/template/tool@latest => my.new/tool'
  'go.octolab.org/template/service => my.new/service'
)

for template in "${templates[@]}"; do
  srcmod="$(echo "${template}" | awk -F' => ' '{print $1}')"
  dstmod="$(echo "${template}" | awk -F' => ' '{print $2}')"
  dir=$(gonew "${srcmod}" "${dstmod}" 2>&1 | awk -F' ' '{print $NF}')
  (cd "${dir}" && make test)
done