Default script entrypoint by kind when frontmatter omits it #91

New Issue

hugo · 2026-07-20T19:44:03Z

hugo commented

2026-07-20 19:44:03 +00:00

Source: Audit section 3.

Spec: specs/frontmatter.allium ScriptFrontmatter and specs/schema.allium Script: entrypoint default is "render" for macros, "main" otherwise. engine/script.rs create_script gets this right.

Current behaviour (RuDS): crates/bds-core/src/util/frontmatter.rs deserialize_entrypoint/default_entrypoint fall back to "render" regardless of kind — a legacy .lua file without an entrypoint field for a utility/transform script rebuilds with entrypoint "render" instead of "main", so execution then fails to find the function.

Task: Kind-aware default: after parsing ScriptFrontmatter, when the entrypoint field was absent, resolve the default from the parsed kind (macro→render, utility/transform→main). Since serde field-level defaults can't see sibling fields, do the fixup in read_script_file or at the rebuild call sites (script_rebuild.rs). Check what bDS2 does for legacy files (../bDS2/lib/bds/scripts.ex / frontmatter.ex) and match. Add tests for both kinds without entrypoint.

Acceptance: Utility script file without entrypoint rebuilds with entrypoint "main"; macro with "render".

**Source:** Audit section 3. **Spec:** `specs/frontmatter.allium` ScriptFrontmatter and `specs/schema.allium` Script: entrypoint default is "render" for macros, "main" otherwise. `engine/script.rs` `create_script` gets this right. **Current behaviour (RuDS):** `crates/bds-core/src/util/frontmatter.rs` `deserialize_entrypoint`/`default_entrypoint` fall back to "render" regardless of kind — a legacy .lua file without an entrypoint field for a utility/transform script rebuilds with entrypoint "render" instead of "main", so execution then fails to find the function. **Task:** Kind-aware default: after parsing ScriptFrontmatter, when the entrypoint field was absent, resolve the default from the parsed kind (macro→render, utility/transform→main). Since serde field-level defaults can't see sibling fields, do the fixup in `read_script_file` or at the rebuild call sites (`script_rebuild.rs`). Check what bDS2 does for legacy files (`../bDS2/lib/bds/scripts.ex` / frontmatter.ex) and match. Add tests for both kinds without entrypoint. **Acceptance:** Utility script file without entrypoint rebuilds with entrypoint "main"; macro with "render".

hugo added the bug label 2026-07-20 19:44:03 +00:00

hugo commented

2026-07-22 16:54:50 +00:00

Implemented in a1c04ff. Script frontmatter now resolves a missing entrypoint after parsing kind: macro defaults to render, while utility and transform default to main. The fix lives in ScriptFrontmatter::from_yaml, so every shared reader (rebuild, desktop, CLI, TUI, metadata diff, rendering, and Blogmark paths) gets the same behavior; explicit entrypoints remain unchanged. Added a filesystem rebuild regression covering all three kinds without entrypoint fields. Neutral review verified specs/frontmatter.allium, specs/schema.allium, and specs/script.allium. bDS2 creation is kind-aware, while its legacy file rebuild currently hardcodes main; the implemented behavior follows the issue acceptance and authoritative Allium contract rather than that bDS2 rebuild inconsistency. Verified with cargo clippy --workspace --all-targets -- -D warnings, cargo build --workspace, and cargo test --workspace (532 passed core tests plus the new regression = 533 total, 1 explicitly ignored; all workspace tests passed).

Implemented in a1c04ff. Script frontmatter now resolves a missing entrypoint after parsing kind: macro defaults to render, while utility and transform default to main. The fix lives in ScriptFrontmatter::from_yaml, so every shared reader (rebuild, desktop, CLI, TUI, metadata diff, rendering, and Blogmark paths) gets the same behavior; explicit entrypoints remain unchanged. Added a filesystem rebuild regression covering all three kinds without entrypoint fields. Neutral review verified specs/frontmatter.allium, specs/schema.allium, and specs/script.allium. bDS2 creation is kind-aware, while its legacy file rebuild currently hardcodes main; the implemented behavior follows the issue acceptance and authoritative Allium contract rather than that bDS2 rebuild inconsistency. Verified with cargo clippy --workspace --all-targets -- -D warnings, cargo build --workspace, and cargo test --workspace (532 passed core tests plus the new regression = 533 total, 1 explicitly ignored; all workspace tests passed).

hugo closed this issue

2026-07-22 16:54:57 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: hugo/RuDS#91