Add tests for page add/remove notifications in dev
When a page file is added or removed, the dev server notifies connected
browsers so that tabs whose content depends on the route list update without
a manual reload. Ten tests pin this down, mirrored across App Router and
Pages Router.
An open tab must be told to re-fetch a predictable number of times. The
test wraps the tab's fetch and counts the requests that carry the
next-hmr-refresh header, which tells a re-fetch the dev server asked for
apart from a navigation or a prefetch: adding a page must produce exactly
two — one from the added-page notification, and one because a page add is
currently also treated as an env change (that false alarm is a separate
problem, marked with a TODO). This fails on both bundlers, in opposite
directions. Turbopack re-announces every existing App Router route on every
update — its added/removed computation compares route keys against entry
maps that key App Router entries by page name ("/page" instead of "/"), so
nothing ever matches — and each announcement makes every connected tab
re-fetch, so the waste grows with the route count (twelve re-fetches per
page add in this fixture). webpack doesn't announce the added page at all
when it sorts after all existing routes: its route-list comparison only
examines the shared index range, and the old list being a prefix of the new
one looks like no change, so the tab re-fetches once instead of twice.
The webpack comparison bug also swallows the Pages Router dev-manifest
update, which is sent from the same block: the manifest re-fetch test fails
on webpack because the update never arrives for an appended route.
A tab showing a 404 must pick up the page once it's added. On Turbopack
there is a window right after a page is added where the server has already
announced it but can't serve it yet. A tab that reacts inside that window
gets the 404 again, and since each page is only announced once, it stays
there. That bug predates this change and is being fixed separately. So that
these tests don't hit the window, they edit the page again once it's
servable, which makes the server announce again — and this time the tab can
only get the page. The cost is that they no longer prove the first
announcement alone updates the tab. The re-fetch count test pins how often
changes are announced, and its tab never sits on the added page's 404, so
it doesn't depend on this ordering.
The remaining tests pass today and pin behavior that a fix to the
notifications must not disturb, across the route shapes the notifications
carry: a 404 tab must also pick up a newly added dynamic route that matches
its URL, and a page added inside a route group (announced under the group-
stripped route name); a tab showing a URL served by a dynamic route must
switch to a more specific page when one is added, and back when it's
removed; a tab showing a removed page must update to the 404 — the App
Router updates it in place, the Pages Router reloads it (its client compares
the exact route name in the message against its pathname, which pins the
naming, including the "/posts/[id]" pattern form for dynamic routes) — and a
Pages Router tab showing a 404 must reload once that page is added.
