Unpopular opinion: If such a tool is useful for you, you are doing something wrong. There is maybe a valid exception for use cases that intentionally create projects that require manual work (university and other trainings), but generally if you spend time by creating the same folder structure over and over again, you're probably working at the wrong level of abstraction. (And if you are creating so many micro services: please stop!)

Or, you just happen to create a lot of directories that are similar? Nothing wrong with that.

I don't think your opinion is "unpopular" but more making unfair assumptions about situations you imagine others to use it, while there is more situations a tool like this could be useful for.

I don't agree. Setting up a brand new project always requires boilerplate code. Either you waste time manually filling in all that boilerplate, or you just create everything from scratch with a helper command.

Microsoft recognized this need by updating its .NET CLI to create projects based on project templates. I know for a fact that at least one FANG has a couple of internal tools to create projects and CICD infrastructure from scratch using project templates.

There are two cases where such a tool could be useful:

1. You have no clue about what "boilerplate" is required or why.

2. You know what's required but you need to generate the boilerplate often.

In the first case, just stop. Using a tool might give you some kind of result, but the quality of what you do is already subpar from the beginning. Learn your effing tools.

In the second case, stop, too. Work with a higher abstraction layer, instead.

> I know for a fact that at least one FANG has a couple of internal tools to create projects and CICD infrastructure from scratch using project templates.

Imagine what that means for the ICs in that FANG: They don't know why the boilerplate is what it is or what part they could or should replace with something more modern .

I typically rely on the framework to have a tool to do this.

When I wrote my own framework, Nexus (for Nim), I wrote a CLI for this sort of thing. It uses variables in naming things, and is quite specialized. I don't think I could use a generic tool.

Unless I'm missing something, it seems like you could just make your template by hand with files and folders and just copy that folder to get the same result?

If you added simple variable substitution to use in filenames and file contents that would kick it up quite a few notches. Especially if you could use the result of bash command instead of static text.

We have a tool to quickly create microservices from a template; from what I remember, it's just a precreated folder with a Go project template which is copied over to the destination with a few fixups like "change the dummy package name to the target name". The hard part is not the copying part, it's to figure out what code should go in the template so that it was useful for most microservices.

P.S. Judging by [0], it wants you to paste template code inside YAML files. If you just precreate an actual project folder on disk and use it as a template (with, say, regexps for fixups), it's going to be easier to work with, as I can edit the template files in the IDE of my choice. Our microservice template is relatively large and changes quite often, it would be a nightmare to edit it and debug it via YAML files.

https://github.com/cemister/scaffold-configs/blob/master/cpp...

Variables were added now

Ayyy nice work! You actually implemented it exactly how I would have lol

Ah, thank you, one correction: not me but a contributor :)

Nice, reminds me of https://yeoman.io/ which was popular couple years ago

Thanks for sharing. How does it compare to copier [0]?

[0] https://github.com/copier-org/copier

Have you tried cookie cutter before? It has a lot more flexibility compared to a yaml config

I wish people would stop needlessly using yaml or claiming it to be a simple format. Show me your yaml spec compliant parser that you wrote in a day.

The number of times I had to think "That would not have happened with a JSON file." ... But I guess the debate is so well known on HN, that I don't need to go into it now.

I wish people would stop seeing the world so black or white.

JSON is not the the be-all and end-all of formats. All formats have their drawbacks, and there is not one format that is THE BEST for absolutely everything.

The author never claimed that YAML is simple, or whatever. But what I can see, is why'd they use YAML instead of JSON for this specific project.

The first thing that comes to mind is multiline strings, as files typically have multiple lines. How'd you do that with JSON? "fn main {\nprintln!(\"Hello\")\n}"? Looks super fun to edit.

> The author never claimed that YAML is simple, or whatever. But what I can see, is why'd they use YAML instead of JSON for this specific project.

I think you should read the OP again.

Would you like to answer a bit more explicitly about what exactly you mean? Or am I supposed to guess the meaning?

> YAML is very easy for both humans and programs to work with and parse, hence why it's the most logical choice in context of Scaffolder.

There is nothing wrong with creating your own type of wheel, but wouldn’t Yeoman achieve the same result?

Yeoman seems to aim towards web applications, scaffolder seems to aim for more generic type of application.

At a glance what makes that painfully obvious is that scoffolder is one binary, while Yeoman is... Well, first it depends on node+npm, then `yo` seems depend on more than 1000 packages.

Of course I'll be biased towards my tool in one or another way, but Scaffolder is much more lightweight and relatively easier to get started with, and as someone else mentioned, it's only a single binary, which adds up to lightweight point.

Looks nice, any plans to add variables and prompts?

I'd recommend adding at the very beginning of the README a short yaml sample. That's the first thing I wanted to look at, but I had to get some understanding and then I found the scaffolder-config repo.

Indeed. Updated the README.

Variables are an interesting idea. I will consider in that in the future.

Hey, variables are there now

This is nice ! I like that you have kept the polyglot world in mind.

You should consider adding: 1) configurability in terms of name ( a templating engine might help ) 2) generate functional build files

And probably keep the project language agnostic, by letting the user specify the content of functional build files.