feat: Implements type inferrence for route params in V4

[LiamMartens]

Mostly non breaking

Description

Created a new proposal for Itty Router v4 to support route param type inferrence. The only breaking change would be for users who are passing generics to their route handlers I believe (ie: Router().get<>) because the path now has to extends string for type inference to work.

Feedback welcome of course

Related Issue

https://github.com/kwhitley/itty-router/pull/150

Type of Change (select one and follow subtasks)

• [ ] Documentation (README.md)
• [ ] Maintenance or repo-level work (e.g. linting, build, tests, refactoring, etc.)
• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
  • [ ] I have included test coverage
• [x] Breaking change (fix or feature that would cause existing functionality/userland code to not work as expected)
  • [x] Explain why a breaking change is necessary: Type inference would never work without generic string params
• [ ] This change requires (or is) a documentation update
  • [ ] I have added necessary local documentation (if appropriate)
  • [ ] I have added necessary itty.dev documentation (if appropriate)

[LiamMartens]

I also saw yarn.lock was updated - but also I saw their are 2 conflicting lockfiles - npm and yarn - wasn't sure which one was the right one - might be worth setting a packageManager in the package.json

[kwhitley]

So I love trying to get inference on route params, but not at the price of a breaking change. v4.x is new enough that yet another [breaking] change in the TS signatures this soon would probably be a sign of general instability in the platform.

[kwhitley]

So unless we can get this in without impacting (in a breaking manner) the existing types, I'm leaning towards closing this for now... 😞

[kwhitley]

Closing this for now... there are more heavily typed approaches to solving this, but itty aims to be the lightweight version of all the heavy approaches.