Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Setext Heading LRDs take precedence over Paragraph LRDs

Chiusa
  • Qualcosa non va?
#298 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@cpruijsen ci sta già lavorando.

Dal 12/10/2026.

  • #313 di @cpruijsen — aperta
  • #314 di @afifm561 — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
38/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
javascript
Ambito
compilers

Direzione di ricerca

Riproduci i due esempi ed esamina Parser.refmap, inline.js e il passaggio di finalizzazione del documento per tracciare quando vengono registrati gli LRD Setext e di paragrafo. Verifica come applicare l’ordinamento proposto senza compromettere le mutazioni di inline.js. Il lavoro è completato quando le etichette duplicate vengono risolte sistematicamente nel primo LRD secondo l’ordine del documento, inclusi i casi di intestazioni Setext.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

The only reference to precedence I could find in the spec is this:

If there are multiple matching reference link definitions, the one that comes first in the document is used. (It is desirable in such cases to emit a warning.)

The issue is that when you define a LRD (link reference definition) in a Setext heading (or a probable Setext heading*), this link will populate the refmap before any paragraph LRDs are parsed, which occurs at the document finalization step.

*A paragraph interrupted by a setext heading underline that only contains links, thus creating an empty <p>, which is immediately unlinked from the AST.

Example inputs:

[x]: fizz

[x]: buzz
===
[x]

has an href=buzz,

Whereas

[x]: fizz

[x]: buzz

[x]

has an href=fizz.

My interpretation of the spec is that both should result in href=fizz as that is the first LRD.

Assuming this is a bug, my idea of a fix would be to use a modified Parser.refmap where it has an Map<number, Array<LRD>> and the key would be the line number of the containing paragraph (sourcepos[0][0]), as the exact lines don't matter as long as the array is populated in-order.

So if this was the input

[line1]: a
[line2]: b
rest of paragraph

[line5]: e
===

would have the map

{
 5: [e],
 1: [a, b]
}

(where a, b, e are objects of typedef LRD {destination: string, title: string, label: string} with map def
Map<number, Array<LRD>>)

Then setext headings' block start and document finalization can occur in the order they do, but could add another step after document finalization. E.g.

/**
 * @param {Map<number, Array<{destination: string, title: string, label: string}>>} unorderedRefmap
 */
function getFinalRefmap(unorderedRefmap) {
  const sortedKeys = [...unorderedRefmap.keys()].sort((a, b) => a - b);
  const finalRefmap = {};
  for (const k of sortedKeys) {
    const values = unorderedRefmap.get(k);
    for (const v of values) {
      if (!finalRefmap[v.label]) {
        finalRefmap[v.label] = {destination: v.destination, title: v.title};
      }
    }
  }
  return finalRefmap ;
}

Something like that should work, its just a matter of adding to the placeholder refmap correctly, which is a bit trickier since inline.js needs a reference to it and mutates it.

Lingua principale
JavaScript
Stelle
1.6k
Fork
234
Merge medio
1g 27m
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di commonmark/commonmark.js

Tutte le issue di commonmark/commonmark.js

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.