I’m not sure how others would feel about this, but I find myself running zig init -m and then grabbing a build.zig from one of my tiny projects, pasting it over the generated one, and changing the binary name every time I want to start a new project. As such, I’d like the ability to put a file somewhere (maybe controlled with an environment variable if people worry about it being opt-in), and have that grabbed, ideally have my project name from build.zig.zon used in it, and have it put where build.zig is when I run zig init -m.
I have thought about building my own init system for Zig, which suggests that a custom template is not a bad idea.
The problem I have with plain zig init is:
It generates a lot of comments. I prefer my starting point to be clean, and I do not like having to delete a large amount of pre-generated commentary. Those comments are useful for first-time users, but they are friction for long-term users.
I still want my library and executable separated. I do not understand why this disappeared from zig init.
I want my own custom logic in the build. I have specific preferences, and they are not the same as everybody else’s. zig init optimizes for a broad target audience, but if I repeatedly work in one specific area, I want zig init to generate something closer to that.
zig build supports fairly advanced use cases. Some people even use it for non-Zig tasks, so it is expected that different users will want an init layout that fits their domain.
Even so, I do not think any of my gripes imply that the default zig init should change. The proposal by Quin to support custom templates for zig init -m seems much more fitting.
I already use zig init -m because I find the default zig init frustrating. If templating is added, I think it should be under its own flag, such as zig init -t, to avoid surprises and to keep -m focused on “minimal” rather than “custom.” I would prefer the template skeleton to live in a standard configuration location, for example:
This sounds like the absolute perfect solution to me I fully agree on the default comments doing nothing but get in the way after my first or second time writing a build.zig, hence my use of zig init -m.
Because it gave the impression to new users that the preferred way to reuse zig code was to build a library.
This is the wrong impression, the preferred way is to export a module.
The ‘library’ code is still separate, it just isn’t built into an actual library, but is exported as a module instead.
I will point out that you can change the non -m template
You’re not a new user, so there is no reason not to change it if it doesn’t fit your common needs
There is also liza for custom templates; linked above.
Editing the template under Zig’s lib directory isn’t really a viable solution.
It assumes write access to toolchain files, which in many setups requires root (system packages, Nix, distro-managed installs), and those changes are reverted on upgrade.
That breaks the usual Unix/XDG config model, where user customization lives in a user-scoped config directory and the toolchain itself is immutable.
You know, I was going to mention that Nix users can’t edit the toolchain files, but then I remembered that Nix users can just use a nix flake template, which is arguably better
