Summary

I'd like to propose adopting mise (formerly rtx) as a single, unified build orchestration layer for the FXServer build, replacing the scattered Windows-centric tooling with one config file (mise.toml) that works identically on macOS, Linux, and Windows. The change is purely additive — existing build paths (fxd, GitLab CI, Visual Studio) continue to work unchanged.

I have a working implementation on a personal fork that compiles FXServer cleanly on macOS ARM (Apple Silicon) for the first time, in addition to Linux and Windows. I'd like to discuss whether upstream is interested before opening a PR.

Problem statement

The current developer tooling is deeply Windows-centric:

• fxd.ps1 and code/tools/fxd/*.ps1 are PowerShell-only and contain hardcoded paths like $env:WINDIR\system32\tar.exe, curl.exe, vswhere.exe, premake5.exe, nuget.exe.
• Linux server builds go through WSL (fxd wsl-build) or code/tools/ci/build_server_docker_alpine.sh running proot inside Docker — there is no native developer entry point.
• macOS has zero support: no scripts, no documentation, the premake5 config breaks on Apple Silicon, and several vendor libraries fail to compile.
• Contributors must install premake5, lua, python, cmake manually with no version pinning. Each fresh checkout invites toolchain drift.
• The build configuration is scattered across fxd.ps1, code/tools/fxd/*.ps1, code/tools/ci/psm1/*.psm1, code/tools/ci/build_server_docker_alpine.sh, code/tools/ci/build_server_proot_alpine.sh, and wsl-build.sh — with no single entry point.

Proposed solution

Add a single mise.toml at the repository root that:

1. Pins tool versions — premake5, lua, python, cmake are declared with exact versions and installed by mise install on all three operating systems.
2. Defines all build tasks — mise run build, mise run gen, mise run server, etc. Each task lives in one block with run (Unix sh) and run_windows (PowerShell) variants.
3. Auto-detects container runtime — podman or docker, transparently.
4. Reuses the existing Alpine image — the only file movement is code/tools/ci/docker-builder/Dockerfile → code/tools/container/Containerfile (renamed to the OCI standard, moved out of ci/ since it's now a developer tool, not just CI).

Why mise over make / just / Taskfile / cmake

mise is the only option that solves both the toolchain problem (getting the right premake5/lua/clang versions) and the task orchestration problem in one tool. The others would need mise (or asdf) alongside them anyway.

cmake would require rewriting hundreds of .lua files and the entire vendor/component system. premake5 works fine cross-platform — there's no reason to replace it.

Tasks

$ mise tasks ls

assemble            Assemble a ready-to-run server directory from build output
assemble:container  Assemble server directory from container build output
build               Build FXServer natively
build:container     Build FXServer in Docker/Podman container (Linux x86_64)
build:debug         Build FXServer natively (debug config)
clean               Remove all build artifacts
clean:all           Remove all build artifacts including generated files
deps                Check and report build dependencies
gen                 Generate build files for FXServer
idl:gen             Regenerate C++ headers from .idl files
natives             Download and regenerate native definitions for server
package             Create a distributable server tarball
server              Assemble and run FXServer locally
server:container    Run FXServer in container from assembled output

A new contributor on any OS does:

git clone --recurse-submodules <repo>
cd fivem
mise install        # downloads premake5, lua, python, cmake at pinned versions
mise run deps       # reports any missing system tools
mise run build      # generates makefiles and compiles
mise run server     # assembles and runs locally

Or for the reproducible Linux build:

mise run build:container   # auto-detects podman/docker, builds in Alpine
mise run package           # produces fx-server.tar.xz

Renames / moves

Updated references in .gitlab-ci.yml, .github/workflows/build_alpine_container.yml, and code/tools/ci/wsl-build.sh.

Cross-platform fixes to existing files

The existing fxd PowerShell scripts also got cross-platform fixes so they keep working as a secondary entry point on macOS/Linux:

• fxd.ps1: Join-Path instead of \ literals; & $script instead of Invoke-Expression (the latter breaks with spaces in paths).
• code/tools/fxd/gen.ps1: detects OS, runs premake5 gmake2 on non-Windows and vs2022 on Windows.
• code/tools/fxd/build.ps1: make on Unix, MSBuild on Windows.
• code/tools/fxd/get-chrome.ps1: platform-aware curl/tar commands instead of curl.exe/tar.exe.
• code/tools/ci/psm1/cfxBuildTools.psm1: platform-aware tool resolution in Get-CfxBuildTools.
• code/tools/ci/psm1/cfxSetupCEF.psm1: Join-Path throughout, platform-aware curl.

Native macOS build support

Getting FXServer to actually compile on macOS Apple Silicon required vendor-level porting work. All changes are guarded by os.istarget('macosx') and don't affect Linux or Windows builds.

Known limitation

JavaScript scripting (libnode22) does not work on macOS in the current state. The libnode22.so/dll binaries committed to git LFS are built from a CitizenFX-patched Node 22.22 source that isn't publicly available — the vendor/node submodule is stuck on cfx/node-16 which is incompatible with the C++ code that uses Node 22 / V8 12.4 APIs.

To fix this we would need either:

1. Publishing the cfx/node-22 branch in citizenfx/node.
2. Adding macOS prebuilt binaries to git LFS alongside the existing Linux/Windows ones.
3. Documentation on how to build libnode22 from scratch (vanilla Node 22 + the CFX patches).

Lua and C# (Mono) scripting work fine on macOS. Most FiveM resources use Lua, so the limitation is acceptable for development workflows.

Why this matters

• macOS contributors can finally build and test without provisioning a Linux VM or container. Faster iteration on cross-platform C++ work.
• One config file instead of seven scripts in three directories. Easier to onboard and easier to maintain.
• Reproducible toolchain — no more "works on my machine" because everyone gets the same premake5 5.0.0-beta8, lua 5.3, etc.
• Container builds work for everyone — the same Alpine image that CI uses, runnable locally on macOS/Linux/Windows for reproducible Linux artifacts.
• Modernization — mise is widely adopted, well-maintained, and the right shape for polyglot projects like this one.

Open questions for upstream

1. Is upstream open to adopting mise as a developer tooling layer? If so, I'll prepare a clean PR.
2. Would you accept the Containerfile rename, or should it stay at Dockerfile for compatibility?
3. Is there interest in publishing a cfx/node-22 branch (or macOS libnode22.dylib prebuilt) so JS scripting works on macOS too?
4. Should the pre-generated IDL headers be committed alongside .idl sources to eliminate Python from the build?

Status

Working implementation on a personal fork — happy to share the branch or open a draft PR for review. The branch is ~16 commits, all guarded by platform filters, fully additive to the existing build paths.