fix: support decimal numbers in route parameters

[thisismyurl]

Routes with parameters like :version now correctly match decimal numbers such as 1.5.1 and semantic version strings.

Previously, a route like Routes::map('download/:version', callback); would work with /download/release but not /download/1.5.1.

Root Cause

AltoRouter's default parameter pattern excludes dots.

Solution

Define custom 'slug' match type with [a-zA-Z0-9._-]+ for all default route parameters.

Changes

• Add custom 'slug' match type to AltoRouter in ensure_router()
• Modify convert_route() to use [slug:param] instead of [:param]
• Add testRouteWithDecimalParameter() test case
• Update docblock comments

Backward compatible: Existing routes continue to work unchanged.

Changelog

• Add custom 'slug' match type to support dots in route parameters
• Modify parameter conversion to use [slug:param]
• Add test case for decimal parameters

Testing

• Added testRouteWithDecimalParameter() test for /download/1.5.1
• Manual verification confirms routes with decimal numbers now work

Credits

Thanks to @thisismyurl (AI-assisted identification and testing)

Closes #45

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR adds support for route parameters that include dots (e.g., semantic version strings like 1.5.1) by introducing a custom AltoRouter match type and updating the route conversion logic, along with a regression test.

Changes:

• Add a custom AltoRouter match type (slug) that allows dots in path parameters.
• Change convert_route() to convert :param segments into [slug:param].
• Add a PHPUnit test covering a decimal/semantic-version route parameter.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.

File	Description
tests/RoutesTest.php	Adds a regression test ensuring routes can match dotted version parameters.
Routes.php	Adds a slug match type and updates route conversion to use it by default.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Levdbas]

Hi @thisismyurl , thank you for this contribution and taking on this long open issue. Copilot did some nitpicking, if you could take a look at those as well, it would be great!

[Levdbas]

@jarednova , can you take a look at this as well/merge?

[jarednova]

Thanks @thisismyurl ! Totally down w this approach to expand the matching set to include decimals. However, this might inadvertently cause some regressions. The code: [a-zA-Z0-9._-]+ would match all ASCII alphanumerics and a few special chars, but cause a regression with other unicode characters and non-included special chars (i.e. /blog/café). Even though that's not in many standard URL practices, I'm want to make sure we're not breaking someone's site unless is absolutely intended (which I don't think it is).

What if we went from [^/\.]++ => to => [^/]++ — this then permits decimals while still excluding slashes. Any downside to that approach? cc @Levdbas

[thisismyurl]

Good call — you're right that [a-zA-Z0-9._-]++ drops Unicode segments like /blog/café, which I hadn't accounted for. [^/]++ is the better shape: it still allows the dots version numbers need, while matching anything that isn't a slash, so non-ASCII segments keep working. Pushed that plus a Unicode test alongside the decimal one (fails against the allow-list, passes with [^/]++). Thanks for catching it before it shipped.

[Levdbas]

Thanks @thisismyurl ! I'm merging this in and we'll ship this in v1