Monolith link lint

How link lint checks the monolith, which holds a copy of every guide without compile.outputFile. Link validation covers the checks that every compiled output gets. The Spec-to-test map names the tests behind this spec.

Links in a guide’s copy

Link lint checks the monolith as a document of its own. A link in a guide’s copy there is checked against the headings of the whole monolith and the section slugs of every copy, the set compile marked each copy against. A section slug is the slug a copy gives a shard’s section, such as a FIND-* finding id or a declared {#id}. Each copy takes that one set. So what passes doesn’t depend on a shard’s owner or on the order of compileOrder.

A link from another output to the monolith passes only on a heading of the monolith, as Validation phases says for a link to any other output of the run. When guide b’s copy stitches FIND-002.md, #find-002 is a section slug and not a heading. So a #find-002 link in guide a’s copy passes, and guides.md#find-002 from a publish output is a dead anchor.

A monolith issue is left out when that guide’s compiled guide reports the same link, with a matching kind and label and a target that matches as written or as the resolved file. Resolved files count because each file rebases paths relative to itself. Link issues match one for one, so each compiled guide issue leaves out at most one monolith issue. Both files keep the lines of the guide’s text, so a monolith issue is matched first to an issue at the same line of that text. An issue left then takes a match on another line, which finds a link whose line a hook moved. That match skips a compiled guide issue when a monolith issue with its label is at its own line, because the issue belongs to the link on that line. Each copy after the first ends with one more blank line in the monolith, and link lint counts it when it finds the line a copy starts on. Link lint reports a monolith issue that stays under the guide whose copy holds its line. The issue sets inMonolith, so its diagnostic names that guide’s copy, (guide "a" in the monolith), and not its compiled guide.

A stale #fragment on a link to another guide in the monolith is reported once for each file, because the two files hold different targets. The linking guide’s compiled guide keeps the link, such as a.md#nope, and link lint reports it as a dead anchor there. The monolith turns the same link into #nope. Compile marks it there, or leaves it when compile.links.markBroken is false, and link lint reports it for the monolith in both cases.

Markers in a guide’s copy

A BROKEN LINK marker in a guide’s copy is reported when that guide’s compiled guide has no marker of the same text. Markers also match one for one, by their own text, because the rest of a marker’s line can differ between the two files. A marker is matched first to a marker at the same line of the guide’s text, as a link issue is. So of two markers with the same text, the one that only the monolith holds is reported. A link gets the same marker in both files, because compile takes each marker’s original target from the shard link at the same place.