11–20 of 29 posts
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.
Variables are an interesting idea. I will consider in that in the future.
There is nothing wrong with creating your own type of wheel, but wouldn’t Yeoman achieve the same result?
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.
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 servic…
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.
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 servic…
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 is nothing wrong with creating your own type of wheel, but wouldn’t Yeoman achieve the same result?
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 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.
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.
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