[Suggestion] Refactor NPM ports out to dedicated third party modules

While working on my own toy Deno server project I noticed that several of the core NPM modules that make up various Node HTTP stacks (from https://github.com/pillarsjs and https://github.com/jshttp) have since been converted to their third party modules (by basically two people!!).

I don’t know if the desire is maintain ports and tests of these modules in this project as a sort of monorepo, or whether there is appetite to keep the focus of Oak lean and use dedicated third parties for non “core” smarts?

Some of the modules in question that look like the easiest swap / best fit are:

• http-errors (./httpError.ts) --> https://github.com/ako-deno/http_errors
• encodeurl (./utils.ts) --> https://github.com/ako-deno/encodeurl

(They have done several others for content negotiation, Vary headers etc. but aren’t necessarily the best fit, or at least stray from how Oak have attacked those areas or aren’t yet implemented in Oak.)

Happy to implement refactors for the two mentioned above if this matches the strategy. 😄

[kitsonk]

Personal opinion, the Node.js ecosystem is littered with single module repos and things have been broken up too much. Those modules that are related to providing an HTTP server I would like to keep in oak and try to keep dependencies down to just std.

So far there are two exceptions to that, media_types, which is maintained here as a seperate repo only because it was moved to std to only have it be “ejected” and needing to take over again. The other is pillarjs/path-to-regexp because it is pretty specific and complex and it is written in TypeScript with no platform specific logic. That is the advantage of the Deno eco-system, in that we can use that discreet bit of logic without any other overhead than expressing that dependency.

Both http_errors and encodeurl are unlikely to ever change in their functionality, so I don’t think maintenance is really an issue. Some could argue why doesn’t ako use the oak modules, as they existed in oak prior to ako and they don’t have to be in a seperate repo to be able to pick and choose using them.

Would be glad to have a chat with @ngot and @wileam about ako and why they felt oak didn’t meet their needs, especially because they are in the same time zone as myself.

[ngot]

Thanks @asos-craigmorten for recommending my ported modules to oak, I really appreciate that. Kudos to @kitsonk for creating oak for Deno developers.

Regarding the questions, let me try to answer,

why they felt oak didn’t meet their needs

That is not the problem of oak, it is mine. When I started to explore Deno, I didn’t find any Koa like framework(Forgive me, I didn’t find oak at the beginning). So, I decided to write a Koa like framework for Deno. I shared that idea on Discord, people told me there was already oak there. I quickly went through oak source code, and find some interesting points:

• It is not going to following koa’s API design
• It is not fully functional compatible with Koa

I understand the reason behind the decision, not all of Koa’s pattern are suitable for Deno. Redesign and make it looks more native to Deno and TS is needed to build a new community.

So, I changed my mind to stop doing duplicated work, but only PORT a Koa compatible framework to Deno instead, even though many designs of Koa might not be the best practice in Deno, and I also want to retain the dark magic of Koa. There are several reasons:

• I personally want a full-feature Koa like framework to migrate my personal project into Deno.
• I believe a PORTed Koa, will bring more people from the Node community to try Deno.
• Even there are many downsides in Koa, but it already proved itself in many production-level projects, if I can port it and migrate a project from Node to Deno, it will give people more confidence to adopt Deno.

single module repos and things have been broken up too

I agree with this. Node modules hell is a nightmare. But I still did that somehow.

Why?

IMO, writing, or maintain a module is different from adopting a module. A high-quality module should be well documented, a good history log, and easy to find. I separate them into dedicated repos is mostly due to the SEO consideration.

But, from an adopter perspective, But what if the host of the URL goes down? The source won’t be available. gives a great guide. Maybe, I should link that page to the document of the ported modules.

Those modules are already in oak, there is no need to link to a third-party module.