WHATWG specifications get significant different output through spec-generator compared to local bikeshed

[annevk]

For instance whatwg/fetch#1922 passes our own CI just fine and all we do is

bikeshed spec "$INPUT_FILE" \
              "$WEB_ROOT/index.html" \
              --md-Text-Macro="COMMIT-SHA $SHA"

as far as I can tell. But when run through PR Preview which uses spec-generator we get a long list of errors:

[
    {
        "lineNum": "492:34",
        "messageType": "link",
        "text": "Multiple possible 'code point' dfn refs.\nArbitrarily chose https://w3c.github.io/i18n-glossary/#dfn-code-point\nTo auto-select one of the following refs, insert one of these lines into a <pre class=link-defaults> block:\nspec:i18n-glossary; type:dfn; text:code point\nspec:infra; type:dfn; text:code point\n<a bs-line-number=\"492:34\" data-link-type=\"dfn\" data-lt=\"code point\">code point</a>"
    },
    {
        "lineNum": "507:50",
        "messageType": "link",
        "text": "Multiple possible 'code point' dfn refs.\nArbitrarily chose https://w3c.github.io/i18n-glossary/#dfn-code-point\nTo auto-select one of the following refs, insert one of these lines into a <pre class=link-defaults> block:\nspec:i18n-glossary; type:dfn; text:code point\nspec:infra; type:dfn; text:code point\n<a bs-line-number=\"507:50\" data-link-type=\"dfn\" data-lt=\"code point\">code point</a>"
    },
    {
        "lineNum": "519:24",
        "messageType": "link",
        "text": "Multiple possible 'code point' dfn refs.\nArbitrarily chose https://w3c.github.io/i18n-glossary/#dfn-code-point\nTo auto-select one of the following refs, insert one of these lines into a <pre class=link-defaults> block:\nspec:i18n-glossary; type:dfn; text:code point\nspec:infra; type:dfn; text:code point\n<a bs-line-number=\"519:24\" data-link-type=\"dfn\" data-lt=\"code point\">code point</a>"
    },
    ...
]

Does anyone here know why that might be the case?

[deniak]

I'm not sure why but bikeshed generates the errors only if we pass the URL of the spec as parameter (which is what spec-generator does):

$ bikeshed spec https://raw.githubusercontent.com/whatwg/fetch/4af534c22feaddb7f8ccbff1adec5f219cc7218b/fetch.bs fetch.html --md-status=LS-PR --md-Text-Macro="PR-NUMBER 1922" --force=1 --print=json --no-update
LINE 492:34: Multiple possible 'code point' dfn refs.
Arbitrarily chose https://w3c.github.io/i18n-glossary/#dfn-code-point
To auto-select one of the following refs, insert one of these lines into a <pre class=link-defaults> block:
spec:i18n-glossary; type:dfn; text:code point
spec:infra; type:dfn; text:code point
<a bs-line-number="492:34" data-link-type="dfn" data-lt="code point">code point</a>
LINE 507:50: Multiple possible 'code point' dfn refs.
...

The errors disappear if we download the file first:

$ wget https://raw.githubusercontent.com/whatwg/fetch/4af534c22feaddb7f8ccbff1adec5f219cc7218b/fetch.bs
$ bikeshed spec fetch.bs fetch.html --md-status=LS-PR --md-Text-Macro="PR-NUMBER 1922" --force=1 --print=json --no-update
$

@tabatkins any idea why this is happening?

[tabatkins]

Oh jeez, no wonder I wasn't getting anywhere trying to figure this out, that's weird. Thanks for the pointer, @deniak ! Now, to figure out what the crap is actually going on...

[tabatkins]

Yup, for some reason I'd stashed the basic link-defaults load in the if-block that checks if I can reasonably look for local files. URL inputs failed that check, and so weren't loading link-defaults at all. Silly mistake, moved it out. (Other things like tar or stdin inputs would fail the same way, and thus are all automatically fixed now.)

(Tho I think I'm doing the check wrong anyway, I should be able to look for other files in the directory when using URL. Not relevant to this issue, tho.)

[annevk]

Okay, so hopefully once spec-generator deploys again this should be fixed. (I just checked and currently PR Preview is still seeing these errors.)

[deniak]

I've just updated bikeshed on the server and the snapshot seems to be generated as expected. @annevk can you please confirm?

[annevk]

I can confirm this is fixed now. @deniak thank you so much for debugging this and redeploying. And @tabatkins thanks for the fix!