jsr icon indicating copy to clipboard operation
jsr copied to clipboard

JSDoc 404s when re-re-exported namespace `export * as is` produces `is.isAny` links

Open tani opened this issue 4 months ago • 1 comments

Summary When re-re-exporting a namespace that itself re-exports many items with renamed exports, JSR's generated docs produce double-qualified names like is.isAny. Those links 404 on jsr.io and break symbol resolution.

Context

  • Library: @core/unknownutil
  • Version: 4.4.0-pre.0
  • Docs page showing the issue: https://jsr.io/@core/[email protected]/doc
  • Pattern:
    • is/is.ts enumerates many re-exports such as: export { isAny as Any } from "./any.ts";
    • is/mod.ts re-re-exports the namespace: export * as is from "./is.ts";
    • mod.ts re-re-re-exports the namespace: export { is } from "mod.ts";
  • On jsr.io docs, symbols appear as is.isAny (and similar), and clicking them yields 404 Not Found. The symbol browser and JSDoc linking seem inconsistent with the actual export graph and/or symbol names.

Minimal Reproduction

  1. is.ts
    export { isAny as Any } from "./any.ts";
    export { isString as String } from "./string.ts";
    // ... many similar lines
    ```
    
    
  2. mod.ts
    export * as is from "./is.ts";
    

Observed Behavior

  • The docs render symbols under a nested path like is.isAny.
  • Links for those nested symbol names point to pages that do not exist, resulting in 404 Not Found.
  • JSDoc for those symbols is either missing or linked incorrectly due to the double qualification.

Expected Behavior

  • Re-re-exported namespace members should resolve to stable, correct doc URLs.
  • Links for symbols should not 404, and symbol names should reflect the actual exported names (e.g., is.Any rather than is.isAny if the public name is Any).
  • The doc generator should correctly handle:
    • export { X as Y } … combined with
    • export * as ns from "…"

Notes and Hypothesis

  • The doc generator may be deriving link targets from internal/original names (e.g., isAny) instead of public aliases (e.g., Any) when nested under a re-exported namespace.
  • Alternatively, the namespace nesting logic might be duplicating the namespace qualifier (is.isAny) instead of presenting the aliased member name (is.Any).
  • Either way, the computed slug or path for the symbol likely does not match the router's expected URL, causing 404s.

What Would Help

  • Clarify which name (original vs. alias) JSR intends to display and link for re-re-exported members.
  • Ensure consistent symbol canonicalization so that:
    • Displayed names match the actual exported surface (including aliases).
    • URL slugs/anchors match those displayed names.
    • Re-re-exported namespaces don't introduce duplicated qualifiers.

Environment

  • Package: @core/unknownutil
  • Version: 4.4.0-pre.0
  • Affected docs: the jsr.io generated documentation pages for the package

Request

  • Please confirm whether this is a known issue in the doc/link generation pipeline.
  • If helpful, I can provide a minimal standalone repo replicating the re-re-export pattern and its resulting broken links.

tani avatar Aug 15 '25 00:08 tani

To fix this, where should we start from?

lambdalisue avatar Aug 26 '25 00:08 lambdalisue

maybe duplicate? https://github.com/jsr-io/jsr/issues/615

ryoppippi avatar Dec 02 '25 12:12 ryoppippi

oh it's about document site, sorry!

ryoppippi avatar Dec 02 '25 12:12 ryoppippi