Inconsistent Error Messaging / Handling in getStaticPaths

Why this is a good first issue

The issue involves improving error messaging for a specific utility function with clear guidance from maintainers.

AI Summary

The issue reports inconsistent error handling in `getStaticPaths` when non-string values are provided as parameters. The maintainer has identified the exact location in the codebase where the fix should be implemented, suggesting a type check and improved error message. There are no apparent blockers, and the fix appears straightforward.

Issue Description

Verify canary release

I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 21.0.1: Tue Sep 14 20:56:24 PDT 2021; root:xnu-8019.30.61~4/RELEASE_ARM64_T6000
Binaries:
  Node: 16.14.2
  npm: 8.5.0
  Yarn: 1.22.19
  pnpm: N/A
Relevant packages:
  next: 12.3.2-canary.22
  eslint-config-next: 12.3.1
  react: 18.2.0
  react-dom: 18.2.0

What browser are you using? (if relevant)

Google Chrome (Version 105.0.5195.125 (Official Build) (arm64))

How are you deploying your application? (if relevant)

Locally via next dev

Describe the Bug

As a preface, this is absolutely human error, but still a possibility to improve error handling and developer experience as I (at least I hope 😅) am probably not the first or last to make this simple oversight.

Additionally, I apologize if this is a duplicate. I did attempt to find an existing report via Google and Github issue search; but at 1.2k open issues, I can't be 100% sure I didn't just miss it.

When creating dynamic routes in combination with getStaticPaths and getStaticProps, error handling does not cover / wrap when a non-string value is supplied as the parameter to a dynamic route.

I was able to Google my error message and figure out relatively quickly that the issue was I forgot to convert my page number from pagination data to a string as the argument for the paths property of the return; but this was not immediately clear.

EDIT: This appears to be as simple as just adding a type check and error to the escapePathDelivers() in router utils, but I am suspicious of it being that easy so a second opinion before I open a PR would be appreciated.

GitHub Labels

good first issue