UPCOMING VERSION v3.0.0 - integrating itty-router-extras into itty-router

So this is a rather big shift/departure from the previous setup, but here are the reasons:

• I use itty-router-extras 100% of the time with itty, and i’m sure many others would too
• currently, without examples using extras in the core lib docs, itty-router looks more verbose than it needs to
• all extras will be released under submodules, allowing the core lib to remain tiny, and the whole project easily tree-shakeable
  • REQUEST FOR FEEDBACK: regarding this, I’m debating an ultra-simplistic itty-router/extras catch-all, or more specific submodules like itty-router/response and itty-router/cors and itty-router/middleware. Honestly, they’re probably all lightweight enough to keep all together for simplicity of end user code… feedback welcome on this though.
• I prefer simplicity in final code implementation above all, and having one dependency of a rather-coupled system (like itty and extras) makes sense over two deps at this stage
• itty-router-extras has not changed appreciably in over a year, suggesting that it’s actually a rather stable API

Thoughts?

[eugene1g]

I don’t expect people to be as sensitive to the bundle size for Cloudflare Workers as we are with SPAs. One dependency with many exports feels more approachable, and people who are super sensitive to the size might be able to do tree-shaking during the bundling process to remove unused code

[kwhitley]

Do you plan to add TypeScript types for itty-router-extras, or rewrite in TS?

For those, I plan to rewrite in TS… just easier than maintaining type files separately.