Improving the Koa ecosystem by moving all Koa modules to the koajs organization!

[jonathanong]

With GitHub's new organization administration, I want to try moving all koa middleware/plugins to the org. The goals are:

• To have shared maintenance of all code.
• Have all middleware/plugins be in one location.
• Create teams so everyone knows who to ask for help.
• Allow members to create repos within the organization.

I'm not sure how this will work. I remember last time, you had to be an owner of the organization for you to transfer a repository to an organization.

The steps will be something like:

• Let us know what repository you'd like to transfer
• We'll create a team for that repository if there isn't one yet
• We'll add that repository to that team
• We'll add you to that team

If anything, just transfer the repository to me and I'll add it to the organization. Comment here so I remember to add it to the organization! Let me know if anyone wants to transfer any repositories.

First one i'd like to transfer is koa-convert :)

NOTE: IF YOU'RE IN THIS ORGANIZATION, PLEASE SETUP 2-FACTOR AUTHENTICATION!

[fengmk2]

Agree! I will transfer all koa relate middlewares/plugins to koajs org.

[jonathanong]

@coderhaoxin are you able to transfer? if not, what's the error message?

[yanickrochon]

I'd like that, too. We can manage teams with an organization and this makes things easier for people to find good quality (and actively maintained) middlewares.

[m4nuC]

I'd transfer https://github.com/m4nuC/async-busboy if that makes sense.

[haoxins]

@m4nuC It seems that async-busboy is not a koa middleware >_<

[tejasmanohar]

I don't think it makes sense to transfer async-busboy since its application isn't tied to Koa.

[m4nuC]

@haoxin yes just a module (It's basically co-body for multipart with koa2 support). It could be made a middleware if that makes more sense.

[tejasmanohar]

@jonathanong Do we really want all middleware that works in the org though? Doesn't having it in the org signify that the org is going to maintain it? Just because it works doesn't mean it's maintained.

[tejasmanohar]

some that would be nice in the org...

• koa-graphql @chentsulin
• koa-bearer-token @chentsulin
• koa-jwt @stiang
• koa-joi-schema @simplyianm

[jonathanong]

We could vote on whether a module is deemed worthy of being in the org or not

[tejasmanohar]

not sure if github sends notifications for @mentions on edits/updates so here are some more :P

• koa-resourcer @aheckmann
• koa-router @alexmingoia

[tejasmanohar]

We could vote on whether a module is deemed worthy of being in the org or not

@jonathanong fair enough, this can get messy in threads. maybe we could get a survey platform? not sure what's good out there... if anyone knows, throw around some suggestions :)

[haoxins]

@jonathanong

When I try to transfer koa-redis-cache to koajs, cache isn't in the teams checklist .

[tejasmanohar]

^ Maybe it's a secret team for some odd reason... :P

[stiang]

Great idea, I’d be happy to transfer koa-jwt. @jonathanong, can you please confirm that you want koa-jwt in the org?

[jonathanong]

@coderhaoxin but you're in the team and see it, right?

@stiang i'll let others decide that. i don't understand JWT :)

[tejasmanohar]

+1 from me for koa-jwt :+1: @stojanovic @jonathanong

[stiang]

@jonathanong Got it, but I’m not really sure who is authorized to say whether I should transfer koa-jwt :) @tejasmanohar, you have already requested it, and I see that you are part of the koajs org. Are you in a position to OK the transfer?

[tejasmanohar]

Nah, let others vote on it and an Owner (who can actually create teams + transfer) decide :)

[stojanovic]

:+1: for the idea

[yanickrochon]

:+1: for a voting system. This will also provide insight of what is actually being used (i.e. I didn't even know about koa-jwt!)

[jonathanong]

what about this: if more than one person wants to maintain it (ex. if someone wants to help @stiang maintain that repository), then it's in.

[jonathanong]

also, if someone could figure out how to easily transfer repos to the org, that woudl be great. otherwise, you can transfer it to me (or another owner) and we'll transfer it here

[tejasmanohar]

if more than one person wants to maintain it (ex. if someone wants to help @stiang maintain that repository), then it's in.

@jonathanong :+1: I agree. @stiang I'm all in to help maintain koa-jwt so you can transfer. My projects depend on it anyways :P

[jonathanong]

sweet. @stiang @tejasmanohar added you both to a new @koajs/jwt team. @stiang if you have trouble transferring it over to the org, transfer it to me and i'll transfer it to this org.

[stiang]

@jonathanong Great! I’ve transferred it now, looks like it’s already available at https://github.com/koajs/koa-jwt

I suppose it should be renamed to just "jwt" to adhere to the naming scheme used by koajs. Also, although I was presented with a list of koajs teams to give permission to, the koa-jwt group was not among them, so I currently don’t have write access to the repo. Could you please add the koa-jwt team manually?

@tejasmanohar Very happy that you are willing to help! I’ve fallen behind on PRs and issues lately, so the project could really benefit from some fresh attention.

[jonathanong]

interesting. when you transferred it over, it was added to no teams, so i had to add it to a team manually.

[stiang]

Yeah, I could have selected another team, but since the relevant one wasn’t displayed I didn’t add it to any. I tried reloading the page and retrying the transfer again, but I still got just a subset of the koajs teams to select from. Not sure what’s going on there.

I renamed the repo to "jwt".

[aheckmann]

If I am a member of a team, am I free to add new teams as well? For example, we have a few koa projects and middleware over at gh://pebble but I wouldn't want to move anything if I can't bring several developers along with it. Does it make sense to (1) create a Pebble team and add people and repos or does it make more sense to (2) stay distributed just leave repos where they are? I'm leaning towards option 2.

[tj]

I don't mind the idea of just everyone having access, if people do weird shit it'll just self-correct haha. That said I don't see a huge problem with using the wiki to list projects, that's still a more condensed view than browsing koajs/*

[niftylettuce]

@tj @jonathanong can you guys add me to @koajs and so I can have collab on https://github.com/koajs/ratelimit? I rewrote it the other day and I want to push it up and release a new major version for koa@next :+1: (it even has support for whitelist/blacklist, and all tests pass with flying sparkles :sparkles:)

[tejasmanohar]

@jonathanong How does moving popular Koa middleware into this org impact the general guidelines we already follow with repos in this org? For example, is it ok to transfer a middleware that's using Babel? What about code style? etc.

@niftylettuce I don't think we should merge that PR yet if koa-convert does the trick. That's the general procedure that all the rest of the middleware in this org has been following.

[jonathanong]

i don't care about code style as long as you have a linter to enforce one.

middleware should be transpiled before publishing anyways, at least for node v4+. i don't see why you need to write middleware that needs to be transpiled though.

[yanickrochon]

A transpiler should not be required when using a middleware; it should only be application-specific. That being said, I personally don't care if one is used, as long as npm install does not pull Babel or anything like that as dependency.

[tejasmanohar]

@jonathanong ah ok. fair enough. @yanickrochon yep, I didn't mean including the full babel-runtime in the package's distribution or anything like that but precompiling instead. that said, I thought we decided not to use Babel in middleware in this org so I thought I'd mention that this may be an issue when/if we transfer external middleware here :)

[yanickrochon]

@tejasmanohar all good :smile:

[ruimarinho]

@jonathanong we can contribute koa-pagination and koa-requestid. Additionally, we are preparing the release of an error mapper which allows registering different mappers to process each error class differently.

@thomseddon might be open to transfer koa-oauth-server, which we currently help maintain too.

[yanickrochon]

I see many people jumping in here, advocating for their projects... and while it's legit, may I suggest to all, no offense intended, that the most downloaded (i.e. popular) get's pulled into the koajs organisation first? I too have koa-* middlewares and one of them has more downloads than some proposed here. Yet, I consider that some middlewares should be promoted first. Like koa-gzip, koa-cors, koa-proxy, koa-timeout, koa-passport, etc.

m2c

[nswbmw]

I’d be happy to transfe:

koa-errorhandler @jonathanong koa-ip @jonathanong koa-mongo @jonathanong koa-scheme @jonathanong koa-router-validator @jonathanong koa-router-cache @jonathanong co-cache @jonathanong

Tip: you can use npm-user-downloads check your packages downloads ranking.

[ruimarinho]

@yanickrochon I think we should take this opportunity not to find which packages have more downloads than the others but to build consensus around them and improve the whole koa ecosystem. I'd be happy to work together on any of the ones I mentioned in case multiple ones from the community are available for the same purpose. Sometimes the multitude of packages on npm comes from the horrible search alone :)

[yanickrochon]

@ruimarinho oh, but I totally agree! My point was that I don't want everybody promoting their own koa-* repositories just for the sake that it has "koa-" as prefix! It's more of a prevention notice, so we don't need to trigger any rejection complex or whatever (LOL)

That being said, usually, the most used (i.e. downloaded) are the ones that should be maintained first (logically). There are cases, however, where you are right and we should take this opportunity to correct, or influence the use of a package over another. For example, there are a few caching middlewares for koa already, some of them perform almost the same thing.

All and all, my point is that community approved packages should be promoted first, so we don't end up with duplicated packages offering the same features yet again.

[ruimarinho]

@yanickrochon agreed! Main areas where I believe there is quite some overlap are caching, routing and error handling.

[jonathanong]

i've setup some teams here: https://github.com/orgs/koajs/teams

• if you want to help with some teams, let me know
• if you think the teams could use better organization (new team, add a module, etc) let me know

i'm sure some modules, even in the org, are not properly organized. looking at the teams might help you guys think about other modules to add to the org!

[jonathanong]

also i noticed a lot of PRs for Koa v2 support. if you see one and want to help, let me know. i don't plan on touching those PRs myself for a while.

[aheckmann]

@jonathanong we (Pebble) have a few repos we'd like to transfer. You want me to transfer to you first or just directly to koajs?

https://github.com/pebble/koa-resourcer https://github.com/pebble/koa-joi-router https://github.com/pebble/koa-resourcer-docs https://github.com/pebble/koa-bunyan-logger

[jonathanong]

@aheckmann you're an owner you should be able to transfer yourself

[tejasmanohar]

(to koajs)

[aheckmann]

cool, will do. thanks

[tunnckoCore]

I can transfer https://github.com/tunnckoCore/koa-ip-filter if you want. I have few more, but they are very outdated and I'm trying to update them soon. Now i'm working on total refactor of koa-better-body, using koa-body-parsers under the hood.

[fundon]

https://github.com/koa-modules/ ?