[Style] stylua format entire codebase

[keithharvey]

Part of BAR type-error cleanup. Rebuilds idempotently from master via just bar::fmt-mig-generate.

# fmt - run stylua across the entire Lua codebase
stylua .

Branch Topology

All branches in the BAR type-error cleanup stack. Regenerated deterministically by just bar::fmt-mig-generate. Generated 2026-04-14 18:57:51 UTC.

Leaves — each targets master, mergeable independently:

Branch	Command	Diff vs master	Units
fmt	stylua	1421 files, +178457 −184495	✅ pass
mig-bracket	bar-lua-codemod bracket-to-dot	341 files, +7632 −7632	✅ pass
mig-rename-aliases	bar-lua-codemod rename-aliases	164 files, +352 −352	✅ pass
mig-detach-bar-modules	bar-lua-codemod detach-bar-modules	173 files, +1434 −1301	✅ pass
mig-i18n	bar-lua-codemod i18n-kikito	19 files, +105 −1187	✅ pass
mig-spring-split	bar-lua-codemod spring-split	760 files, +9591 −9587	✅ pass
mig-integration-tests	bar-lua-codemod integration-tests	21 files, +1230 −1151	✅ pass
mig-busted-types	bar-lua-codemod busted-types	12 files, +1501 −0	✅ pass

Rollups — composite branches stacking the leaves and (for fmt-llm) the env + LLM layers:

Branch	Diff vs master	Diff vs mig	Units
mig	1452 files, +189169 −194574	—	✅ pass
fmt-llm	1480 files, +189970 −194795	126 files, +861 −281	✅ pass

[github-actions]

Integration Test Results

16 tests  ±0   8 ✅ ±0   3s ⏱️ ±0s
 1 suites ±0   8 💤 ±0 
 1 files   ±0   0 ❌ ±0 

Results for commit 9db1f79. ± Comparison against base commit d88bed3.

♻️ This comment has been updated with latest results.

[keithharvey]

Problem

lx fmt is only formatting src/, spec/ directories because that is what it expects a lua package to look like (kind of dumb imo).

Notably lx --lua-version 5.1 lint does not have this problem and passes the entire directory.

Solution

lx --lua-version 5.1 exec stylua . {{args}} is what we have to do instead to run against the world

or
just bar::fmt over in BAR-Devtools

Problem here is that introduced a LOT of changes. I was surprised how few changes there were the first time so that explains it.

just bar::lint passes now

...
Checking /var/home/daniel/code/Beyond-All-Reason/weapons/spybombx.lua OK
Checking /var/home/daniel/code/Beyond-All-Reason/weapons/treefire.lua OK

Total: 0 warnings / 0 errors in 2199 files

[WatchTheFort]

Isn't linting something we want to run on the dev's machine before they push, rather than as an action after?

[keithharvey]

Yes. The README contains recommendations to set up a github hook. We can also add that to the setup script over in BAR-Devtools. This is more to catch people that didn't do that.

• I should probably add a recommendation for vscode setup and extensions to auto format as well
• Another option would be to auto-format when it hits the CI, that's less contrib friction but potentially surprising. I would just force the hook by catching them with the linter for now but I'm open to just doing it in the CI too. Maybe for now adding a github workflow that CAN format for us, so we can just nuke PRs from orbit as a one-off with a stylua pass wouldn't be a terrible migration strategy here.

Edit:
@WatchTheFort I did both of these things, but most relevant to you is that I added a workflow that you can run against arbitrary PRs (untested).

[WatchTheFort]

Where did this number come from? The solution for excessively long lines is better formatting, or better code architecture, not arbitrarily splitting across multiple lines.

[keithharvey]

Where did this number come from?

120 is stylua's own default. Industry standard range is 80-160; 120 sits in the middle.

The solution for excessively long lines is better formatting

This is better formatting -- it's automated formatting.

or better code architecture

That's a stylistic judgment call, which is exactly what we're trying to get out of the business of making manually. A formatter with a column width handles it consistently so developers don't have to debate it in review.

Having a max line length beats not having one. Without it, lines grow unchecked, diffs get wider (more merge conflicts), and side-by-side review becomes painful. 120 gives a concrete answer to "how long is too long" so we stop relitigating it per-PR. If a specific line reads better long, -- stylua: ignore above it opts out.

[efrec]

nibbles

[keithharvey]

Related PR Comments

• Necessary Trailing comment noise cleanup - [Style] stylua format entire codebase #7199 (comment)
• [Style] stylua format entire codebase #7199 (comment)

@WatchTheFort @efrac -- closing thoughts on #7199 for tonight.

Why we're not hand-editing this PR

We don't want to deviate from the generated output any more than we already have. Right now this branch is: CI changes, a format command, and a few targeted manual fixes (the -- stylua: ignore comments for those unreachable-code test blocks, the empty do/end header). The further we drift from that, the faster we have to merge it, because this thing will be merge conflict central for every in-flight branch. But if we keep it close to a pure stylua . pass, anyone can re-run the formatter on their branch and conflicts just go away. Comment cleanup, bracket-to-dot refactors, engine globals -- all good ideas, all follow-up PRs after this one lands.

PR comment threads

I've resolved the threads I consider addressed. If you disagree on any particular closure, please reopen the ones you think still need discussion. Otherwise I'll take silence as agreement.

Migration guide for contributors with in-flight branches

Here's the playbook. I just did this with sharing_tab (3 commits, 100+ files, ~37 conflicts) and it took about 2 minutes.

Step 1: rebase onto master (after #7199 merges)

git fetch origin
git rebase origin/master

Step 2: at each conflict, take your version and re-format

# for pure formatting conflicts (most of them), take yours:
git checkout --theirs <conflicted-files>

# for files your branch deletes:
git rm <file>

# then re-run stylua on everything you touched:
stylua <conflicted-files>
# or if you use BAR-Devtools:
just bar::fmt

# stage and continue:
git add -A
git rebase --continue

If you're confident all your conflicts are formatting-only (no overlapping logic changes with master), you can batch the whole thing:

# ⚠️  only safe when ALL conflicts are pure formatting, not semantic
git diff --name-only --diff-filter=U | xargs git checkout --theirs --
stylua .
git add -A
git rebase --continue

That's it. The formatter is idempotent -- your logical changes survive and the formatting matches master.

If you use BAR-Devtools: just bar::fmt wraps the same stylua . pass, and just bar::setup-hooks installs a pre-commit hook so you never push unformatted code again. If you want to set up stylua on your host machine directly instead, see the "Manual Tooling Setup" section in the BAR README.

Caveat: the BAR-Devtools recipes (bar::fmt, bar::setup-hooks) exist locally but haven't been pushed to thvl3's upstream yet -- @thvl3 has been AFK. Until those land, run lx fmt or stylua . directly.

[keithharvey]

Also added .git-blame-ignore-revs so this commit is transparent in git blame. GitHub picks it up automatically. Locally it's one config line (git config blame.ignoreRevsFile .git-blame-ignore-revs).

[Ruwetuin]

does #7229 now supercede this PR?

[keithharvey]

does #7229 now supercede this PR?

Kind of. That PR is a superset of all changes. This is a generative step in the migration process. 7229 is everything. It would be easier if we roll them out together probably, but each PR represents a different step. This PR is the style base.

fmt - 'stylua .'
^
Mig1 - dots conversion
^
Mig2 - spring split
<< mig branch

There's also transform leaf branches.

Fmt > mig1
> mig2

This allows you to preview each transform independent of the style changes.

All of this is kicked out automatically by a script for me so it shouldn't drift and we can add more transforms easily and see previews.

edit: I modified the script to kick out a topology so all of this is more clear. Also split the transform leaf PRs up into completely individual (I had put spring and the global rename together for convenience before all this was scripted)