• Joined on 2026-04-03
alexion pushed to task-0003-view-skeleton at alexion/kitchen-md 2026-07-28 21:21:24 -04:00
ae542893da refactor: model bin errors as neverthrow Result values (task 0003)
alexion pushed to task-0003-view-skeleton at alexion/kitchen-md 2026-07-28 20:46:54 -04:00
313a5b60b7 test: remove roadmap todos from parse_test.ts (task 0003)
alexion pushed to task-0003-view-skeleton at alexion/kitchen-md 2026-07-27 22:55:02 -04:00
11866a0dd5 feat: scope test report to given paths, default all (task 0003)
alexion pushed to task-0003-view-skeleton at alexion/kitchen-md 2026-07-27 22:51:31 -04:00
0b6a52452a build: add test report generator (task 0003)
alexion pushed to task-0003-view-skeleton at alexion/kitchen-md 2026-07-27 22:23:57 -04:00
3d81d1c76e build: set up test coverage via bun (task 0003)
alexion commented on pull request alexion/kitchen-md#2 2026-07-27 22:15:58 -04:00
feat: kitchen view command and parser skeleton (task 0003)

Agreed — index.ts here is a pure re-export barrel (export { parse } from "./parse.ts"; export type * from "./types.ts";), so these tests were stranded at the entrypoint. Moved them (real tests + roadmap todos) into a co-located parse_test.ts importing parse from ./parse.ts, and deleted index_test.ts — commit e32b71e. A broken re-export is still caught by typecheck and by the bin package importing parse through the public entrypoint in its E2E test. (Note the same doesn't apply to bin/index.ts, which is the actual CLI with logic, so its index_test.ts stays.)

alexion pushed to task-0003-view-skeleton at alexion/kitchen-md 2026-07-27 22:15:34 -04:00
e32b71ebf3 test: move parser tests to parse_test.ts, off the barrel (task 0003)
alexion commented on pull request alexion/kitchen-md#2 2026-07-27 22:08:30 -04:00
feat: kitchen view command and parser skeleton (task 0003)

I don't think this is a useful test.

alexion commented on pull request alexion/kitchen-md#2 2026-07-27 19:23:19 -04:00
feat: kitchen view command and parser skeleton (task 0003)

Frontmatter is a mapping type (Record<string, unknown>), but YAML can also parse to a bare scalar (e.g. 42), a top-level sequence, or null/~. The three conditions narrow to exactly a plain mapping — both null and arrays report a typeof of object, which is why the explicit !== null and !Array.isArray are there. Everything else normalises to {}, matching the spec: empty when the block is present but invalid. If we later want 'present but not a mapping' to be visible rather than silently {}, that is a natural fit for an invalid-frontmatter-style diagnostic in task 0007.

alexion commented on pull request alexion/kitchen-md#2 2026-07-27 19:23:19 -04:00
feat: kitchen view command and parser skeleton (task 0003)

It is the map-or-drop idiom: translateBlock returns [] to skip an unmodelled node or [block] to keep one, and flatMap flattens that in one step, with no nulls or holes. It also generalises unchanged to task 0004, where a single mdast node can translate to several core blocks (and containers recurse into their children). Not about empty files — an empty input is just tree.children === [], handled the same way regardless. translateInline uses it for the same reason. Happy to switch to an explicit push-loop if you find that reads clearer.

alexion commented on pull request alexion/kitchen-md#2 2026-07-27 19:23:19 -04:00
feat: kitchen view command and parser skeleton (task 0003)

Correct — nothing constructs one yet; diagnostics is always [] in this slice. Trimmed in 8687b75: dropped Point, Position, and the source?/position? fields, leaving Diagnostic as { severity, code, message } — just the element type of the returned (empty) array. Task 0007 emits the first real invalid-frontmatter diagnostic and re-adds the locator fields additively, with its own tests.

alexion pushed to task-0003-view-skeleton at alexion/kitchen-md 2026-07-27 17:41:24 -04:00
8687b7501a refactor: trim Diagnostic to fields produced this slice (task 0003)
alexion commented on pull request alexion/kitchen-md#2 2026-07-26 21:10:22 -04:00
feat: kitchen view command and parser skeleton (task 0003)

Why use flatMap if the array returned is always of size 0 or 1?

alexion commented on pull request alexion/kitchen-md#2 2026-07-26 21:10:22 -04:00
feat: kitchen view command and parser skeleton (task 0003)

Why are we being so restrictive with what types of yaml parsed?

alexion commented on pull request alexion/kitchen-md#2 2026-07-26 21:10:22 -04:00
feat: kitchen view command and parser skeleton (task 0003)

Is this ever created anywhere? The only diagnostics I see is always an empty array.

alexion pushed to task-0003-view-skeleton at alexion/kitchen-md 2026-07-26 08:19:37 -04:00
97ecc86d63 test: add prose-fixture end-to-end smoke for kitchen view (task 0003)
alexion merged pull request alexion/dotfiles#36 2026-07-26 08:08:25 -04:00
fix(guests): keep a networked guest's resolver and order it after its bridge
alexion pushed to main at alexion/dotfiles 2026-07-26 08:08:25 -04:00
f218e47814 docs: note the repo pins no formatter and nix files aren't nixfmt-clean
53a070a59a fix(guests): keep a networked guest's resolver and order it after its bridge (task 0010)
Compare 2 commits »
alexion deleted branch task-0010-guest-vm-integration-test from alexion/dotfiles 2026-07-26 08:08:25 -04:00
alexion created pull request alexion/kitchen-md#2 2026-07-26 07:25:25 -04:00
feat: kitchen view command and parser skeleton (task 0003)