Tweaks on top of taralx PR...

[kwhitley]

Notable Changes

• preserve existing signature (no second param) to matching any existing introspection schemes - maybe cost a few characters, but it's a bit more future-proof/robust to potential future options we add.
• Router options are now:
  • base?: string - optional base path
  • routes?: any[] - optional array of routes (for introspection or preloading with advanced regex)
  • unrelated: adds a bit of added interface for the internal Request definition to address #47
  • unrelated: export TS interfaces to address #38
  • thanks to the @taralx refactor, we can now support preloading routes, which means those rare edge cases of crazy regex (previously not possible) requirements, can now be force-fed into the router (at config stage, or even after... also thanks to the more exposed router.routes array. Pretty sick!

Example of manual loading routes:

// EXAMPLE 1 mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
it('allows preloading advanced routes', async () => {
  const basicHandler = jest.fn(req => req.params)
  const customHandler = jest.fn(req => req.params)

  const router = Router({
                  routes: [
                    [ 'GET', /^\/test\.(?<x>[^/]+)\/*$/, [basicHandler] ],
                    [ 'GET', /^\/custom-(?<custom>\d{2,4})$/, [customHandler] ], // match 2 to 4 digits only
                  ]
                })

  await router.handle(buildRequest({ path: '/test.a.b' }))
  expect(basicHandler).toHaveReturnedWith({ x: 'a.b' })

  await router.handle(buildRequest({ path: '/custom-12345' }))
  expect(customHandler).not.toHaveBeenCalled() // custom route mismatch

  await router.handle(buildRequest({ path: '/custom-123' }))
  expect(customHandler).toHaveReturnedWith({ custom: '123' }) // custom route hit
})

// EXAMPLE 2 mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
it('allows loading advanced routes after config', async () => {
  const handler = jest.fn(req => req.params)

  const router = Router()

  // allows manual loading (after config)
  router.routes.push([ 'GET', /^\/custom2-(?<custom>\w\d{3})$/, [handler] ])

  await router.handle(buildRequest({ path: '/custom2-a456' }))
  expect(handler).toHaveReturnedWith({ custom: 'a456' }) // custom route hit
})

DISCUSSION: If we change r to routes, and prevent the prebuild.js from mangling it, the filesize does grow (405b --> 409b), but so does the legibility around this weird introspection. Thoughts? I'm all for absolute minimum filesize, but... legibility. Torn. Don't think we would have to count the decision on this one as a breaking change (if we opt for "routes"), because the existing pattern isn't documented, and is hopefully only used in debugging patterns at most. Regardless of the path chosen here, documentation will be added to disclose this functionality.

UPDATE: unless there's strong objection, I'm opting for readability over ultimate filesize... router.routes it is

Filesize Comparison (pretty sure this includes the type declaration, so appears artificially inflated a bit)

• current: https://bundlephobia.com/package/itty-router@2.3.10
• @next ("routes"): https://bundlephobia.com/package/itty-router@2.3.10-next.0
• @next ("r"): https://bundlephobia.com/package/itty-router@2.3.10-next.1

[cloudflare-pages[bot]]

Deploying with    Cloudflare Pages

Latest commit:	e0dda8e
Status:	✅  Deploy successful!
Preview URL:	https://05c33027.itty-router-y9b5.pages.dev

View logs

[kwhitley]

@taralx

[taralx]

:+1:

[taralx]

:+1: still

[kwhitley]

Gonna document a bit and cut it loose (hopefully tonight). BTW, any idea how to cut the size bundlephobia sees? We're getting 479 bytes gzipped (not really relevant) and minified (definitely relevant)... but I get ~408 bytes testing locally.

[taralx]

What is bundlephobia?

[kwhitley]

Analyzes bundle size... basically the real cost of adding a module to your project.

https://bundlephobia.com/package/itty-router@2.3.10

[taralx]

I poked at bundlephobia, and they're using webpack to "build" the package. I suspect it's measuring some webpack overhead.