Here's something I've been writing last couple of days: https://github.com/vedranvuk/boil
The focus is much more on the parametrization of template files. Still very raw though.

I wrote a similar tool a while back for Wails. Would love to see this as part of the standard tooling: https://github.com/leaanthony/gosod

Neat idea!

a few thoughts:

versioning for templates with @ similar to the go get syntax would be great to pin templates keeping scripts that utilize go new from breaking.

Eg go new example.com/foo@v1.2.3.

after looking at the package itself, it already supports versioning! Just the projen comment then

——

have you heard of Projen before ? The TLDR is that it is a tool that eschews static one-time templates in favor of programmatic updates over the life of a project.

imagine your project was bootstrapped with v1.1 of example.com/fooTemplate. With projen, you can upgrade to v1.2 in an automated fashion. This could involve adding, deleting, or editing files.

I don’t think it’s necessarily something the go tool chain would support natively, but I just figured I’d mention it as it’s in the same orbit as templating, but takes the devils advocate approach of “templates are bad” (their words, not mine).

just a thought!

Is it possible to contribute to this tool? I was thinking of having template files that can be populated with user passed configuration variables (when the command is executed) and transpiled into Go files. Kind of like helm charts.

One use case that I can think of is to have a standard header in every file like for example the used license.

A common use for a scaffolding tool is to fill in the boilerplate for an extension to a framework where an extension can either be a third party shareable module or a project-specific subdirectory.

This tool would work for either situation if it's okay for the extensions to be sub-modules or dependencies. That's certainly doable but I imagine not everyone would want to deal with that.

It would be useful if there were a way to "adopt" the template as part of the current module. The easy part would be rm go.mod and the more involved part would be first merging the template's dependencies into the adopting go.mod.

For more context, I'm specifically thinking of the sort of thing I mentioned in a previous reply: #61669 (reply in thread)

Thank you for bringing this discussion up. We have heard that Google uses a mono repo and it's very impressive. However, due to the lack of tools and expertise, we as an external company can't do the same. Therefore, we have to duplicate some parts of our logic for each project. To handle this, we decided to set up a separate repo and copy common parts of code, such as working with NATS and Redis, in that repo and use it in our projects. With this approach, the go get command will help us to eliminate most of the duplicate code and import it into our projects.

But some issues can't be resolved with this approach and we still need to duplicate some logic for each project. For example, if we want to support Redis in a project, we have to manually add the initialization and shutdown parts, call the monitoring parts, and add the configuration and deployment files as well. The problem gets worse when we need to refactor some parts of our common module and replace the old code with a better alternative.

When I read this discussion, based on this experience, I think we are not alone and maybe this kind of issue can lead to better tools.

Let me think aloud, if the go get command modifies the external directory (~/.local/share/go/pkg/mod/ directory), the gonew command will modify and weave local files and directories. And if we have a standard tool with developer-friendly API, it can change the way we structure our projects. All of this can reduce some more manual work from us.

$ gonew example.com/ourteam/redis

$ tree . # if the gonew command modify the local files.
.
├── docker-compose.yaml
├── .gitlab
│   └── ci
│       └── templates
│           └── test.redis.yaml
├── src
│   ├── config
│   │   └── defaults.redis.go
│   │   └── redis.go
│   └── app
│       └── app.redis.go
└── deployment
    ├── templates
    │   └── config-map.redis.yaml
    └── values.redis.yaml

$ tree . # if the command can modify and weave the local files.
.
├── docker-compose.yaml
├── .gitlab
│   └── ci
│       └── templates
│           └── test.yaml
├── src
│   ├── config
│   │   └── defaults.go
│   └── app
│       └── app.go
└── deployment
    ├── templates
    │   └── config-map.yaml
    └── values.yaml


$ go generate ./...
$ go mod tidy

I apologize for the long description but I wanted to bring up the problem to find a better approach.
Thanks.

In my team, we have a simple UI where I can put the name of the project and some additional features that I can choose when starting a new project like:

• add DB support (it adds to the source code everything that's needed to access the DB with basic migrations)
• add redis support
• add message bus (RabbitMQ in my case)

It'd be awesome to be able to create similar functionalities with gonew. I can see the usage like this

gonew github.com/path/template.git github.com/myorg/myproject --param redis=yes --param db=yes

or something similar. The idea is simple: we are able to add high-level parameters that help us customize the created project. It should be able to edit(template) files and create/skip specific files based on those parameters.

Those features should be good enough to do what, for example, @kamilsk said to customize any infrastructure-related things like CI/CD, generating docker-compose files, and much more.

gonew github.com/path/template.git github.com/myorg/myproject --param ci=githubactions

Really cool, I need to give it a try.

It is really good to see gonew working over this initial interaction. @rsc am I right in thinking that the modules being used to create a new module are meant to be fully functioning standalone and not templated themselves? I see translating an example project into a templated syntax to be a barrier to maintenance. I see the original module as being a fully working standalone project and not having to be adapted for the gonew tool.

It feels that working over the go.mod and the directory name would give enough information to adapt references to internal imports that might be in the module.

It feels like in the go module landscape all modules should rename useable and not a combination of traditional modules and templated sytntax modules.

Hopefully I have been able to explain myself. In short I think gonew is a positive start 😄

go new

1. extracts the module files locally
2. renames the module

Both of these are valuable on their own. Renaming a module obviously so. Extracting files less so, but it would be useful.† If those were separate commands then go new as it is would just be a helper to run those two in the correct order with the correct args.

† Consider a web framework that by convention embeds all its template files on an exported Templates variable and has a naming system that lets you override a dependency's template file. Handy on its own but you usually want to start from the original template instead of from scratch. It's already in the module cache so being able to ask go to grab just that file from the module being used is simpler than going to github and finding the file at the correct version.

requests for extensions so far generally fall into two categories

1. templating
2. refactoring

I think it's unlikely that templating will be included. Some basic package renaming would be nice but also seems unlikely given how awkward to specify this would be.

In both cases you could use some tool after you call go new to get the desired results but you may not know that you have to so there would probably be some kind of "read me first" file though you may not know to look for it. If the file name were standardized, maybe go new could cat it before exiting.

Alternately, while generally go doesn't run arbitrary code, maybe this could be the exception as it's meant to be run once by a developer. If there were a standard go tool/generate command name to run at the end it could collect any additional information and run any templating/refactoring.

Suddenly seeing this discussion, it is very interesting that our team also developed a similar tool in the past two years and used it extensively internally. This greatly contributes to improving development efficiency, especially in the case of microservice development.

It's worth mentioning that we also supported caching and generating project structure based on module paths. However, the caching mechanism implemented in "gonew" is more elegant, we will also consider learning from it and optimizing our own implementation.

Running this command below would generate a project in github.com/douyu/exampleapp directory with github.com/douyu/exampleapp module name.

jupiter new github.com/douyu/jupiter-layout github.com/douyu/exampleapp

Once gonew is merged into the official Go repository, we will immediately replace and start using it. 😄

Refer:

• https://github.com/douyu/jupiter/tree/master#quick-start
• https://github.com/douyu/jupiter/blob/master/pkg/core/cmd/cmd_new.go

I was excited to use gonew but I had a issue that I want to share it with you.
I have a repository in bitbucket.org/company/project-name but in project module name is company.com/project-name which is using in imports and go.mod file. So when I use gonew bitbucket.org/company/project-name new-project, it will not replace imports as new-project because it use module name as bitbucket.org/company/project-name and try to replace it with new one.

I made a quick solution for myself by cloning gonew and adding new command line flags in this repo but maybe you can think of this issue and find a better solution.

To echo others who have requested input parameters, it'd be great if I as the template author could tell gonew to unmarshal yaml or json provided by the template user into a struct accessible from the templates. The use case is to have the user provide values like a hostname or url.

What about repositories which have multiple Go modules?

For instance it is quite common to follow https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module. You can take a look at https://github.com/goyek/goyek which has tools as a separate Go module. This pattern is especially important for libraries so that its users do NOT depend on the libraries' build tools. However, it could also profit for applications (e.g. CLI apps) as it should speed up the time of building the applications using go install. Here is an example GitHub repository template that creates two Go modules which is good for libraries https://github.com/goyek/template.

I want to be positive about experiments and contributions to the go ecosystem. I realise that we need to cater to developers of all levels and sometimes a problem that seems trivial to someone familiar with go may be a challenge to a developer just arriving from another language. That said, I don't see what problem gonew solves in its current state.

Looking at the gonew source it's just replacing the old module name with the new name in source code. This is not a challenging problem to solve for someone who wants to copy an existing repo to a new namespace.

When i saw the announcement I had hoped for something similar to cookiecutter, which i've been using for years to help bootstrap new projects. This has been incredibly useful to my teams in crafting and reusing project templates for go and other languages.

I think the current version of gonew is effectively a conversation starter (and this discussion is the conversation!). What I hope is that gonew becomes something similar to what we're doing with cookiecutter so that we have a go native tool for bootstrapping projects and a common language for defining project templates. This would seem to be something easily built on top of text/template in conjunction with a project template specification.

Is this the direction we're likely to head?

I think this can be useful. It can save people coding time if there are maintained standard code templates for common things like a web server, etc. similar to how some Google-internal server frameworks create the initial files.

One con to keep in mind is that making things easier to write is not always the best thing. Copying over a large amount of boilerplate code over and over without understanding and real need can make things less maintainable over time (if there is not a refactoring to some dependency that is maintain, the folks who copied the code would need to maintain the copy).

So it might be good to think about the ecosystem and maintainability impact of having such a tool.