chore(ci): verify giscus comment threads still map to their articles - #168

🏁 Script executed:

printf '%s\n' '--- repository conventions ---'
find /tmp/coderabbit-repo-knowledge/decipher-stuar-tc-6e0cf60b -type f -name '*.md' -maxdepth 3 -print
printf '%s\n' '--- verify-giscus.mjs ---'
cat -n nuxt/scripts/verify-giscus.mjs
printf '%s\n' '--- related giscus and article references ---'
rg -n --glob '!node_modules' --glob '!dist' 'verify-giscus|Giscus|giscus|article\.path|writing/' nuxt

Repository: Decipher/stuar.tc

Length of output: 27619

🏁 Script executed:

printf '%s\n' '--- script conventions ---'
cat /tmp/coderabbit-repo-knowledge/decipher-stuar-tc-6e0cf60b/conventions/nuxt-scripts.md
printf '%s\n' '--- article data convention ---'
cat /tmp/coderabbit-repo-knowledge/decipher-stuar-tc-6e0cf60b/conventions/nuxt-content-articles-data.md
printf '%s\n' '--- giscus component and relevant tests ---'
cat -n nuxt/app/components/AppGiscusComments.vue
sed -n '30,58p' nuxt/tests/components/AppGiscusComments.spec.ts
printf '%s\n' '--- article path/filename invariant ---'
sed -n '115,138p' nuxt/content.schema.ts
sed -n '1,38p' nuxt/tests/content/articles-data.spec.ts
sed -n '420,482p' nuxt/scripts/sync-content.mjs

Repository: Decipher/stuar.tc

Length of output: 11448

🌐 Web query:

Giscus strict matching false API discussions resolver exact semantics term pathname

💡 Result:

In Giscus, strict matching is a feature that overrides the default fuzzy search behavior used to resolve GitHub Discussions, providing a deterministic and exact mapping between your web page and the discussion [1][2]. When data-strict="1" is enabled, Giscus changes how it searches for discussions: 1. Mapping Resolution: Giscus first resolves the chosen mapping (e.g., pathname, title, og:title) into a specific value based on your configuration [3][4]. 2. SHA-1 Hashing: Instead of using this raw value as a search term in GitHub's discussion API, Giscus calculates the SHA-1 hash of that value [1][3]. 3. Body Search: Giscus then searches the body of discussions in your configured category for this specific SHA-1 hash [1][3]. Because Giscus searches for this hash within the discussion body rather than matching titles, the discussion title itself becomes irrelevant to the mapping process [3][5]. This allows you to use robust, stable identifiers like the page's pathname while maintaining the ability to change page titles without breaking the comment link [5]. Key Requirements for Strict Mode: - Integration: For existing discussions, you must manually edit the discussion body to include the SHA-1 hash of the mapping value (e.g., the pathname) [1][3]. Giscus automatically includes this hash in the body of any new discussions it creates [1][3]. - Format: The hash does not need to follow a specific format or be an HTML comment; as long as the SHA-1 string is present anywhere in the body, Giscus will successfully resolve the discussion [1][3]. - Reliability: This approach eliminates the risk of "fuzzy" matching errors where Giscus might incorrectly link to a discussion with a similar but incorrect title [1][2].

Citations:

• 1: https://github.com/giscus/giscus/blob/main/ADVANCED-USAGE.md
• 2: https://giscus.app/
• 3: GitHub issue 508 in giscus/giscus (link omitted to avoid creating a cross-reference)
• 4: https://blog.arkey.fr/2022/10/16/moving-from-disqus-to-giscus/
• 5: GitHub issue 832 in giscus/giscus (link omitted to avoid creating a cross-reference)

🌐 Web query:

site:github.com/giscus/giscus ADVANCED-USAGE.md strict matching fuzzy search discussion title pathname

💡 Result:

In the context of the giscus commenting system, the ADVANCED-USAGE.md documentation outlines the data-strict attribute as a solution to address issues with GitHub's default fuzzy search behavior when locating discussions [1]. By default, giscus uses GitHub's fuzzy search to find a discussion based on its title. This can sometimes lead to the incorrect discussion being selected if multiple discussions have similar titles [1]. To ensure an exact match, users can enable strict title matching by setting data-strict="1" on the giscus script tag [1][2]. When strict matching is enabled, giscus switches from searching by discussion title to searching for a SHA-1 hash of the title within the discussion body [1]. Key requirements for strict matching: 1. Enabling: You must set data-strict="1" in your giscus configuration [1][2]. 2. Migration: For existing discussions, you must manually edit the discussion body to include the SHA-1 hash of the title [1][2]. 3. Automated Handling: New discussions created by giscus after this feature was introduced automatically include the hash as an HTML comment (e.g., ), ensuring they are compatible by default [1]. 4. Flexibility: The hash does not need to be in any specific format; it only needs to be present somewhere in the discussion body [1][2]. While giscus documentation discusses mapping discussions to pages (often using the discussion title as the identifier), it does not natively provide a "pathname" mode as a primary configuration for discussion lookup in the same way it addresses strict title matching. The primary mechanism for ensuring a precise, non-fuzzy link between a page and a discussion is this SHA-1 based strict matching [1][2].

Citations:

• 1: https://github.com/giscus/giscus/blob/main/ADVANCED-USAGE.md
• 2: GitHub issue 508 in giscus/giscus (link omitted to avoid creating a cross-reference)

🏁 Script executed:

printf '%s\n' '--- repository convention files ---'
find /tmp/coderabbit-repo-knowledge/decipher-stuar-tc-6e0cf60b -type f -name '*.md' -print
printf '%s\n' '--- relevant convention headers ---'
head -5 /tmp/coderabbit-repo-knowledge/decipher-stuar-tc-6e0cf60b/*/*.md 2>/dev/null
printf '%s\n' '--- target file outline ---'
ast-grep outline nuxt/scripts/verify-giscus.mjs
printf '%s\n' '--- target file ---'
cat -n nuxt/scripts/verify-giscus.mjs
printf '%s\n' '--- runtime and script contracts ---'
rg -n 'lint:giscus|verify-giscus|engines|node-version|setup-node|AbortSignal|fetch\\(' package.json nuxt package-lock.json .github 2>/dev/null | head -200

Repository: Decipher/stuar.tc

Length of output: 11654

🏁 Script executed:

printf '%s\n' '--- script convention ---'
cat /tmp/coderabbit-repo-knowledge/decipher-stuar-tc-6e0cf60b/conventions/nuxt-scripts.md
printf '%s\n' '--- repository manifests and workflows ---'
git ls-files | rg '(^|/)(package(-lock)?\.json|pnpm-lock\.yaml|yarn\.lock|\.nvmrc|.*workflow.*\.ya?ml)$|verify-giscus'
printf '%s\n' '--- references to the checker and Node version ---'
rg -n -S 'verify-giscus|lint:giscus|node-version|engines|22\.23\.2|setup-node' . --glob '!node_modules/**' --glob '!dist/**' --glob '!build/**' 2>/dev/null | head -200

Repository: Decipher/stuar.tc

Length of output: 12655

🏁 Script executed:

printf '%s\n' '--- nuxt package manifest ---'
cat -n nuxt/package.json
printf '%s\n' '--- CI workflow relevant sections ---'
rg -n -C 8 'setup-node|node-version|lint:giscus|pnpm|working-directory' .github/workflows/ci.yml .github/workflows/preview.yml
printf '%s\n' '--- package manager and Node constraints ---'
rg -n -C 3 'packageManager|engines|node-version|NODE_VERSION' nuxt/package.json nuxt/pnpm-lock.yaml .github README.md .nvmrc 2>/dev/null | head -120

Repository: Decipher/stuar.tc

Length of output: 25245

🌐 Web query:

Node.js 22 global fetch default timeout AbortSignal.timeout fetch documentation undici headersTimeout

💡 Result:

The global fetch implementation in Node.js (which uses the Undici library under the hood) does not have a built-in "default timeout" property in the fetch options [1][2]. Instead, it relies on underlying socket connection, header, and body timeouts [2][3]. Key points regarding timeouts in Node.js fetch: 1. AbortSignal.timeout: The standard way to implement a request-level timeout in fetch is to use AbortSignal.timeout(ms) [4][1]. This will cause the fetch promise to reject if the operation exceeds the specified duration [1]. 2. Undici Defaults: Node.js fetch is powered by Undici, which applies default timeouts at the connection and protocol levels [2][5]: - headersTimeout: Defaults to 300 seconds (300,000ms), which is the time allowed for the server to send complete HTTP headers [6][2][3]. - bodyTimeout: Defaults to 300 seconds (300,000ms), which is the time allowed between consecutive body chunks [6][2][3]. - connectTimeout: Defaults to 10 seconds (10,000ms), which is the time allowed to establish the initial socket connection [7][3]. 3. Configuring Timeouts: Because these are managed by the internal Undici dispatcher, you cannot modify them through standard fetch options (like { timeout:... }) [1][8]. To change these defaults, you must provide a custom dispatcher with an Agent configured to your needs [9][2][5]: import { fetch, Agent, setGlobalDispatcher } from 'undici'; // Example: Configuring custom timeouts const agent = new Agent({ connectTimeout: 5000, headersTimeout: 10000, bodyTimeout: 15000 }); // Apply globally setGlobalDispatcher(agent); // Or use per-request await fetch('https://example.com', { dispatcher: agent }); Note that AbortSignal.timeout is generally the recommended approach for limiting total request time, as it is standard-compliant and works consistently across environments [1]. However, if you specifically need to adjust connection-level or parser-level timeouts (e.g., to shorten the 10s connect timeout), using a custom dispatcher as shown above is required [7][9][2].

Citations:

• 1: https://devcraftly.com/nodejs/native-fetch/
• 2: https://undici.nodejs.org/getting-started
• 3: https://github.com/nodejs/undici/blob/main/docs/docs/api/Client.md
• 4: https://nodejs.org/docs/latest-v22.x/api/globals.html
• 5: https://github.com/nodejs/undici?tab=readme-ov-file
• 6: https://undici.nodejs.org/api/Client
• 7: GitHub issue 4215 in nodejs/undici (link omitted to avoid creating a cross-reference)
• 8: GitHub discussion 1989 in nodejs/undici (link omitted to avoid creating a cross-reference)
• 9: https://stackoverflow.com/questions/76755913/increase-timeout-in-nodejs-built-in-fetch-api