Commit 744ce0e
committed
fix(xpkg): 0.0.47 and 0.0.48 were swallowed by a malformed 0.0.49 entry
`mcpplibs.xpkg@0.0.48` stopped resolving — openxlings/xlings#486. The index
file parses as valid Lua, which is why nothing caught it: the damage is
semantic, not syntactic.
0.0.49's entry lost its `sha256` line and its closing brace, so every entry
below it became a FIELD OF 0.0.49 rather than a sibling:
["0.0.49"] = {
url = { ... },
["0.0.48"] = { ... }, <- nested
["0.0.47"] = { ... }, <- nested
sha256 = "45f23...", <- 0.0.49's, orphaned down here
},
Lua reads that happily. `xlings info mcpplibs:xpkg` then listed
0.0.50, 0.0.49, 0.0.46, 0.0.45 — with 0.0.47 and 0.0.48 simply absent, and
absent reads exactly like never published.
Mine, from #156: the reorder that moved 0.0.49 to the top of the list used a
non-greedy regex, which stopped at the closing brace of the nested `url`
table instead of the entry's own. Half the entry moved; the tail stayed.
Verified by parsing the file with lua5.4 and enumerating the keys — 9 versions
before, 11 after. A structural check is the only thing that would have caught
this, since every text-level check passes.1 parent 1804459 commit 744ce0e
1 file changed
Lines changed: 2 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
24 | 24 | | |
25 | 25 | | |
26 | 26 | | |
| 27 | + | |
| 28 | + | |
27 | 29 | | |
28 | 30 | | |
29 | 31 | | |
| |||
37 | 39 | | |
38 | 40 | | |
39 | 41 | | |
40 | | - | |
41 | | - | |
42 | 42 | | |
43 | 43 | | |
44 | 44 | | |
| |||
0 commit comments