feat: a folder's own URL lands on its first page - #1
Closed
gitKrystan wants to merge 6 commits into
Closed
Conversation
The entry for the co-located pages links at `rootURL + 'Home'`, where no page is served: those pages live in the root URL space, under no group name. The branch meant to handle that tests for a group named 'root', and the build has named that group 'Home' since 158bf9d, so it never fires. Two consequences. The link is wrong — a redirect round-trip through `handlePotentialIndexVisit` where an app wires it on the top-level wildcard (docs-app), a hard 404 where it does not (test-apps/multiple-docs-routes). And `@homeName` does nothing, because it is read only inside that dead branch. The test app now passes `@homeName` and asserts the label, the root href, the active state, and that nothing points at /Home. Verified against main in kolay's own docs-app too. Found while working on universal-ember#366, which touches this component; split out so it can land on its own. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The all-links crawl in markdown-only asserted an exact visit order that included `/Home` seven times — the URL this fix stops linking to. With the link pointing at the app root, the crawl follows the root's redirect to the first group instead. Caught by CI rather than by me: I ran lint and the one test app this diff touches before pushing, and markdown-only is neither. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gitKrystan
force-pushed
the
gitkrystan/collections
branch
from
August 14, 2026 00:42
8465924 to
9a64466
Compare
…up-nav-home-link fix(GroupNav): the Home link is the app root, not /Home
…node-24.x chore(deps): update node.js to v24.19.0
`/Group/sub-folder` names a real place in the docs but no document of its own, so visiting one rendered the error page. It now redirects to that sub-tree's first page — the rule a group's own URL already follows, applied one level down. These are URLs readers type and link by hand. Path resolution only ever normalized the `.md` extension (`samePagePath`), which is why an extensionless *page* URL resolved while a sub-tree's URL matched nothing at all. The index-page concept already existed for the nav (`getIndexPage`, and sorting hoists `index.md` to the top of its tree); this puts it in front of routing, so a tree with an index page lands there and one without lands on its first ordered page. Two things worth knowing while reading this: - The new branch runs only after a page lookup misses. An ordinary page visit lands on the wildcard's index too, with the page as the wildcard param, and must be left exactly where it is. - That page lookup is manifest-wide rather than `findByPath`, which searches only `currentGroup` — and `currentGroup` derives from `router.currentURL`, which still names the *previous* page while a transition is being resolved. The wildcard holds only the part of the URL below the mount, so a mount with a path of its own needs its group put back on the front: a scoped mount names it in the binding, an unscoped nested mount takes it as its path, and a top-level mount's wildcard already carries it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gitKrystan
force-pushed
the
gitkrystan/folder-index-redirect
branch
from
August 14, 2026 16:56
88306e8 to
32b9bd6
Compare
Owner
Author
|
Superseded by universal-ember#370 — rebased onto upstream main (this was stacked on the unmerged universal-ember#366) and renamed to the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on
gitkrystan/collections(universal-ember#366), because it touchesFolder— the type that branch renames. Retarget atmainonce universal-ember#366 lands.The gap
/Group/sub-foldernames a real place in the docs but no document of its own, so visiting one renders the error page. Readers type and link these URLs by hand; on one large internal docs site, 5 of 9 broken links found by a link-crawl were exactly this shape.Resolution normalizes only the
.mdextension:So
/Group/sub-folder/pageresolves (extensionless page URLs work), while/Group/sub-foldermatches nothing.handlePotentialIndexVisitalready redirects a group's own URL to its first page — this applies the same rule one level down.Approach
Redirect rather than resolve. Rendering the index page at the folder URL would give one page two URLs, and the nav's active state compares
currentURLviasamePagePath, so the folder URL would highlight nothing. Redirecting also makes folder roots and group roots behave identically.The target is the folder's first page. Sorting has already hoisted
index.mdto the top of the folder that holds it, so that is a folder's index page when it has one, and its first ordered page when it doesn't — one rule, both cases, and the same rulegroup.list[0]encodes at the group root.Two subtleties, both called out in comments:
handlePotentialIndexVisitdescribes.findByPath.findByPathsearchescurrentGroup, which derives fromrouter.currentURL— during a transition'sbeforeModelthat still names the previous page.And the mount translation: the wildcard holds only the part of the URL below the mount, so a mount with a path of its own needs its group put back on the front. A scoped mount names it in the binding; an unscoped nested mount takes it as its path (the route above the wildcard); a top-level mount's wildcard already carries it. The unscoped-nested case is the one I got wrong first —
/demos/componentswas looked up as/components.API
One method on the docs service,
landingForFolder(appRelativePath), and two pure helpers inbrowser/utils.ts(findFolder,firstPageIn). Nothing existing changed shape.Tests
docs-app/authoring→/authoring/index), folder without (/development→/development/rendering-pages), trailing slash, casing, a page's URL is left alone, a path that is neither still errorscustom-root-urlmultiple-docs-routes/help/getting-started, mount space ≠ manifest space) and an unscoped nested mount (/demos/components)Results on this branch:
multiple-docs-routes— 18/18 passvirtual-routes-only— 5/5 passdocs-appvia the dev server (/tests/?skipAllLinks) — 102 tests, 371 assertions, 0 failed, 5 skippedcustom-root-url— 12 pass, 4 fail;markdown-only— 1 pass, 1 failThose 5 failures are pre-existing on
gitkrystan/collections. I verified by stashing this change, rebuilding, and re-running both apps: identical failures. They all come from the Home group's nav link becoming/instead of/Home, which those apps'nav-active-stateand crawl snapshots still expect — worth a fix on universal-ember#366 before it merges.One caveat: a built
testem cirun ofdocs-appalso showed 11 failures, all 120–180s timeouts in<ComponentSignature>/<HelperSignature>/<ModifierSignature>/gitRef. The dev-server run of the same suite is fully green and none of those modules touch routing, so I read them as environmental — but I did not baseline that particular run, since it takes ~20 minutes.🤖 Generated with Claude Code