feat(build): split settings daemon CSS/JS into their own files (#140)#145
Merged
Conversation
Second slice of the source split. The settings daemon embedded ~640 lines of frontend as Python triple-quoted strings (STYLE = """<style>...""", SCRIPT = """<script>..."""). Move the CSS to modules/src/settings.css and the JS to modules/src/settings.js, leaving @@include@@ markers the assembler resolves (nested: css/js -> daemon.py -> agent-box.nix). Now eslint/stylelint/prettier and `node --check` can see real frontend files. Both blocks have zero Nix interpolation and can't contain triple-quotes, so they round-trip verbatim through the Python-triple-quote host and the outer Nix string. Verified: the assembled modules/agent-box.nix is byte-identical to the pre-split hand-written file except the GENERATED banner — no behavior change. Note: the shell start/attach scripts and the Caddyfile are deliberately NOT extracted — they use Nix `${...}` interpolation and must stay in the template. Validated: module-generated-up-to-date, module-single-file, and the settings-page VM test all green; `node --check modules/src/settings.js` parses. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Sw7j9FYnbChZJbYArxbhuo
The generated modules/agent-box.nix can be reassembled from unchanged bytes by a pure source refactor (e.g. moving the daemon CSS/JS into their own files), which touches no *.nix path — so CI's `**.nix` filter skipped it and the module-generated-up-to-date guard never ran. Match the generator inputs explicitly: the .in template (ends in .nix.in, not .nix), modules/src/**, and the assembler script. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Sw7j9FYnbChZJbYArxbhuo
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part 2 of issue #140, on top of #143. Splits the settings daemon's embedded frontend into real files so linters/formatters can see it.
What changes
The daemon carried ~640 lines of frontend as Python triple-quoted strings (
STYLE = """<style>…""",SCRIPT = """<script>…"""). This moves them to:modules/src/settings.css(123 lines)modules/src/settings.js(518 lines)leaving
@@include:...@@markers that the assembler resolves. Includes now nest two levels —settings.css/settings.js→settings-daemon.py→agent-box.nix— which the generator already supports (each child is escaped for its immediate host's string syntax; the Python triple-quote host needs none).node --check modules/src/settings.jsparses, and the CSS/JS are now reachable by eslint / stylelint / prettier — the static-analysis gap the issue called out.Zero output change
The generated
modules/agent-box.nixis untouched by this PR — the diff is only the three source files. The CSS/JS re-assemble to the exact same bytes, so there is no behavior change and nothing new for deployed boxes to fetch.Scoped out (on purpose)
The shell start/attach scripts and the Caddyfile stay in the template — they're densely Nix-
${…}-interpolated (per-user names, ports, socket paths), so their content can't move to a plain file. The Caddyfile's only static, self-contained fragment is a mostly-comment header plus one 7-line snippet; not worth a file. (If Caddyfile static-checking is wanted, a better route is a CI check that runscaddy validate/caddy fmt --diffon the rendered output — happy to add separately.)Validation
Green locally:
module-generated-up-to-date,module-single-file, and thesettings-pageVM test (daemon serves the page + password-change flow).🤖 Generated with Claude Code