Version 2

[markusahlstrand]

It seems to be time to modernize this library a bit.

The first step will be to convert it to typescript and make sure it works with both hono and cloud-worker router.

[markusahlstrand]

Ongoing work available here #122

[tomlarkworthy]

I agree the destination should be TS + Hono and deprecate cloud-worker, but there are a few different paths there and it might be a lot of work to get there with leaving the project in an undeployable state. The handlers have been tested so I think we should try to get there without breaking the existing handler logic.

For TS support I recommend bun.js instead of node.js. It runs TS out-of-the-box and outputs a JS blob with its integrated bundler. So that would also remove webpack. Node.js is only used for local testing so using bun.js for local testing is not that much of a change and bun is closer to worker environment than node is (though node 18 is much better in that regard now). Its also about 100x faster so it nicer to work with.

Hono is better overall but it would be a breaking change. I think the way I would tackle this refactor is translate your existing matching syntax to hono in 1st step. So we can get it working without breaking existing code and make sure all the test work before then doing the final refactor on the router syntax (the breaking change).

For tests we use mocha, but jest won the war. Bun supports jest out of the box. Getting tests to work with typescript is quite painful configuration.

So overally my point would be to try and fix the TS toolchain and tests to align with bun.js before tacking Hono migration. Its just an idea though, I am not sure how mock-fetch works with bun.js

Hono is written in TS. I think the first priority is getting TS toolchain working, whether by bun.js or a more conservative node.js approach. We should be able to do that without a big V2 fork.

[markusahlstrand]

I haven't yet had time to try out bun, but that would be interesting. I guess what we mostly need is to run the typescript compiler so maybe we can do it without any build tools?

Agree that jest is the way to go. Added that to the v2 branch now.

It seems that changing to hono was a pretty minor change, but it's a good point that we ideally should be backwards compatible.. Maybe we can have a wrapper of the proxy that is a legacy-mode that we eventually deprecate?

[tomlarkworthy]

well typescript is a build tool. Workers only run .js so to TS has to be added in somewhere, it is part of a future toolchain somewhere. I acknowledge bun might feel too new presently, so I will not push it hard.

If hono was easy then I guess lets go with it. I do think deprecating cloud-worker, is a big win so if this V2 version flip is not painful lets go for it. I just want to avoid a situation where there is a partially functional V2 branch kicking around for extended time.

LMK if there is an orthogonal feature I can help with.

[tomlarkworthy]

BTW, I am presentl testing the limits of the s3 handler so thats a place that I will contribute by default unless you need help elsewhere. seems like the s3 handler would survive the v2 fork anyway.

For example, s3 is a standard API with compatible providers like backblaze and R2, so the current approach of hardcoding the service-url will be one place I definately want to abstract a bit.

[markusahlstrand]

I'm just moving the origin handler now, but I can do a basic migration of the S3 handler after that so you can check it out and improve further on it :)

Currently I'm running a Hono-version from the example folder and I'm don't think the packaging of the proxy works right now.. If you have a good idea to make that in Bun it would be great!

[tomlarkworthy]

So this switches from node.js to bun.js as the test runner #124

you can use TS files directly now in tests. To use TS files on the core source code path, we need to do a bit more.

With bun you don;t need esbuild because bun bundle does the same thing

[tomlarkworthy]

I think to get where we really want to get to is we need to change in the
"main": "src/index.js",
to
"main": "dist/index.js",

and insert a TS compilation steps that takes the src directory and writes an "dist/index.js". This is as easy as npx bun build ./src/index.js
I am not sure how much that will mess up the examples though.
There is alternative of just using JSDoc annotations to add the TS types and then we do not need to mess with the source structure so much https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html

[tomlarkworthy]

There is significant merge backlog, so this PR looks like it has a lot of unnecessary changes, but those will dissapear once the backlog is clear. This is a working migration to TS https://github.com/markusahlstrand/cloudworker-proxy/pull/131/files, in a previous PR I added a final integration test so I am fairly confident this works and is backwards compatible to the existing codebase. I did not bother actually fixing the Typechecker, there are tons of typecheck failures but this doesn't actually block the build process which does work.

I would like the backlog cleared before I invest the time to get that PR typechecking working.

Typescript migration: https://github.com/markusahlstrand/cloudworker-proxy/pull/131/files