This would offer a local unified web page for the Zig process, replacing the current ones (std docs, fuzzing)
The desired features/settings could be governed by a serve.zon which you put in your project root directory, some or all of which could also be available as command flags on the CLI.
zig serve could offer a lot of things, using a nice interface that only shows what’s relevant.
Some uncontroversial ideas:
Watch/compilation progress
Autogenerated docs for your project + stdlib
Build-graph visualization
The fuzzing interface
Dashboard showing everything going on
Some wilder ideas:
Built-in gotta-go-fast/benchmarking UI for the project, with history/graphing
A Zig package discovery and distribution facility, perhaps based on a Kademlia network similar to BitTorrent.
I bet many community members would be willing to run zig serve in package-distribution mode on cheap VPS’s or at home to help with package distribution. Built-in mirroring, servable from any Zig installation.
Some sandboxing required:
Distributed CI? What if people could donate resources for CI purposes? Anyone could chose who to accept Zig CI requests from (such as ZSF), and anyone could chose who to request CI resources from. Could be served on a VPS, or on a home server.
Distributed compilation, integrated with the cache? Mainly to distribute package compilation for desired targets; could be useful for very large projects.
Just noting that, for the ZSF in particular, we only want CI machines that we have full control over, ideally physically. So we wouldn’t likely use such a feature.
(This is not meant to dismiss any of the ideas in principle, to be clear.)
Is there a difference between distributed cache and distributed compilation? I can see the utility of remote cache to allow all machines to “pick up where somebody else left off”, (see Bazel remote cache). But I don’t see as much utility in distributed compilation (multiple compilation machines), because truly incremental compilation will reduce compilation times 99%.
I see truly incremental compilation as a paradigm shift in simplicity. Its a solution that can delete large amounts of complexity (distributed systems).
Yeah that is my thinking too for most cases, the use-case would be very large projects (think a browser made in Zig) where you frequently integrate changes in many packages, some of which are perhaps C or C++ libraries. However, if incremental ends up working in even these cases, then the feature is moot.
Reminds me that in the past I had added a simple web server to a game engine for debugging purposes. A game would serve HTML pages which allowed to inspect the internal game- and engine-state - very useful at the time.
Today I would do such things fully ingame via Dear ImGui (since a game is doing rendering anyways, so hooking up a debug UI is trivial, esp with Dear ImGui). The web server approach still makes a lot of sense for any type of headless code.
I really like the idea, of easy access to a visual profiler.
Getting one that does not introduce unexpected slow downs of itself, setting it up correctly for Zig and then hoping it would work cross-platform, is really painful. (or a skill issue on my end )
What i see, at least in the Zig projects nowadays, a lot of them dont have auto-doc setup, it would make it a more accessable feature.
One important fix would be to not include the whole stdlib in the project’s autodoc, because doing that adds about 13 MBytes to each doc webpage via the sources.tar file. In sokol-zig I unpack this file, remove the stdlib sources and repackage and this drops the size down to 0.5 MBytes so that it is more manageable for hosting on GH Pages.
Ideally the generated autodoc for projects would link to https://ziglang.org/documentation/[version]/std/ for any stdlib references.
I actually wonder how package dependencies are handled, do those also show up in the generated autodoc webpage?
)