sdods analyze invented 18 page routes out of directories that happen to be called pages

Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.

We are App Router only. No pages/ directory anywhere near the router. But:

bash

sdods analyze ../platform --report-only

comes back with a routes table full of things that do not exist:

text

kind   method  path                        source              file
page   -       /{id}                       next-pages-router   app/api/intranet/pages/[id]/route.ts
page   -       /{id}/publish/route.test     next-pages-router   app/api/intranet/pages/[id]/publish/route.test.ts
page   -       /{id}/archive               next-pages-router   app/api/intranet/pages/[id]/archive/route.ts

Eighteen of them. The same paths also appear correctly as api rows from the App Router detector, so I get both the right row and the wrong one. Is my repo laid out badly or is this the tool?

cli config

asked by Sergio Alcaraz

2 answers

Accepted answer
Your repo is fine. This is the Pages-Router detector.
Its path pattern is not anchored to the router root, so it matches a pages/ segment anywhere in the relative path — including app/api/intranet/pages/[id]/route.ts, where "pages" is your own resource name. Three things then compound:
- the App Router branch already matched and emitted the correct row, and nothing arbitrates
between the two, so you get both
- that branch has no test/spec exclusion (the Express one does), which is where
route.test.ts becomes a route
- the path is sliced from the regex match rather than from the router root, so the parent
segments are lost and /api/intranet/pages/[id] collapses to /{id}
There is an open issue for it and it is not fixed. What makes it bearable is that the failure is completely predictable: every phantom row sits under a directory literally named pages. On a repo with no such segment the detector is silent.
Workaround, and it is the whole workaround: keep using --report-only, drop the bad rows out of the proposed routes: map, and only then --apply. If you have already applied, the map is a plain block in projects/<slug>/sdods.project.yaml and deleting the rows costs nothing — just do it before anyone writes a feature that navigates by one of those keys.
Do the same pass on modules:. A phantom route usually drags a phantom module in with it.
answered by Reeta NandalSDODS team
Cheap way to know how bad it will be before you run anything:
bash
```
find . -type d -name pages -not -path '*/node_modules/*'
```
Every hit that is not an actual Pages Router root is one to several bogus rows. We have a pages resource too (a CMS) and it produced exactly the shape Reeta describes.
answered by Marijn Kuiper

Know the answer?

Wrap commands and output in triple backticks and they will render as a code block.

Checking whether you’re signed in…

Have a different question? Ask it.

sdods analyze invented 18 page routes out of directories that happen to be called pages

2 answers

Know the answer?

Related