fix: in sortRoutePaths: sort files alphabetically

[will-weiss]

The fix for the bug described was found with the assistance of Claude Opus 4.6. The analysis presented is from the AI, not my own, but I can confirm that the workaround it presented (which it said was based on its findings) did work for my use case.

What I observed

For our fresh 2.2.0 project I observed that on github actions builds middleware defined in routes/app/_middleware.tsx were not running before the handler defined in routes/app.tsx after vite build. This was not the same behavior I observed when testing locally on my Mac.

I pulled down the generated /_fresh directory from github actions and instructed Claude to look to see if there were any differences in those files generated during the github actions build and those generated by running the same commands on my mac.

From Claude Opus 4.6

@fresh/core's sortRoutePaths function has a bug on lines with return charA <
  charB ? 0 : 1 — when charA < charB, it returns 0 (equal) instead of -1 (a before b). This
  makes the comparator asymmetric: compare(a, b) can return 0 while compare(b, a) returns 1.

  On macOS, Deno.readDir returns files alphabetically, which happens to produce the correct
  final sort even with the broken comparator. On Linux (CI), Deno.readDir returns files in
  hash-table order. The stable TimSort algorithm + inconsistent comparator + different initial
  ordering = /app/_middleware ends up at position 112 instead of position 4, so the auth
  middleware never runs for /app routes.

  Fix: scripts/fix_fresh_route_order.ts re-sorts the fsRoutes array in
  _fresh/server/server-entry.mjs after the build using the correct comparator. It's wired into
  deno task build so it runs automatically on both local and CI.

The referenced workaround script scripts/fix_fresh_route_order.ts overwrites the route ordering in the generated _fresh/server/server-entry.mjs file after that has been built by vite build. While I have not evaluated the contents of that script line by line, I did scan it and it does seem to be doing what is suggested and I can confirm that it did fix the issue, suggesting that the overall analysis is sound.

Closes #3773

[bartlomieju]

Thanks!