Conversation
🦋 Changeset detectedLatest commit: 317660e The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| validateGetStaticPathsParameter(next, routeComponent); | ||
| const [key, value] = next; | ||
| acc[key] = typeof value === 'undefined' ? undefined : `${value}`; | ||
| acc[key] = value?.toString(); |
There was a problem hiding this comment.
This is more concise and works for undefined, numbers, and strings, but does require support for the ?. operator. Since this support was added in Node.js 14.0.0, this should be OK.
A PR merged back in April changed the type of Params, allowing numbers to be provided in addition to strings. See withastro#3087. However, as said PR changed the type of Params instead of GetStaticPathsItem, it also affects Astro.params. This commit moves the change to GetStaticPathsItem, reverting the type of Astro.params.
bholmesdev
left a comment
There was a problem hiding this comment.
I param very impressed! Great change 👍
|
While our API reference page does in fact say that
So, no objections from docs if we're now all rallying behind Team String, but our error reference will have to change to match. (cc @Princesseuh @matthewp ) |
|
Thanks @sarah11918. The error reference looks correct to me as-is. |

Fixes #5442.
/cc @tony-sull & @bholmesdev
Changes
#3087 changed the type of
ParamsfromRecord<string, string | undefined>toRecord<string, string | number | undefined>to formerly allowgetStaticPathsto return numbers.However, as the change was made to
Paramsand notGetStaticPathsResultorGetStaticPathsItem, it also affectsAstro.params.This PR essentially moves the change made in #3087 from
ParamstoGetStaticPathsItem, reverting the type ofAstro.paramswhile keeping the type ofgetStaticPaths.Note that while looking into this, I found this comment by @bholmesdev:
In my experience,
Astro.paramsnever contains numbers, not even in static mode. While reviewing, please consider that this PR changes the types to match the behaviour, although judging by this comment, we might want to change the behaviour to match the types instead.Testing
This is testable like so:
I haven't found any type definition tests to which this one could be added.
Docs
From what I understand, this change is in line with the current docs: