should we move web framework core modules to another org?
dead-horse opened this issue · comments
It is a little confused that core modules like accepts / mime-types mix in with express middlewares like session / csurf.
I don't really know. They are all maintained by the same people (organization), but yes, they are not all identical in what they do. But I see this in all the orgs I look at on GitHub, where there would be that mixing in the same org.
Basically to me, you're asking "should we divide GitHub orgs by the members (currently how it is) or divide them by the functionality of the contents".
I think if we make an organization that is just expressjs middleware, everyone will feel left out, because their module won't be listed there or something.
Basically to me, you're asking "should we divide GitHub orgs by the members (currently how it is) or divide them by the functionality of the contents".
Yep. I think most of people come to expressjs org just interested in express middlware modules(look at the stars), those core modules worth to be hightlight.
Maybe if we divide orgs by contents, people who want to write web frameworks can find these useful modules much easier. Not sure, haha. (idea came from @jonathanong 's xxx-utils orgs)
Nah, this is an org for the development of express-related things. Some of those thing will be sub-modules and middlewares that work without express.
The middleware is already listed on connect, and when this website is up, we'll list them there. If people are just looking for middleware, we'll point them to that.
That sounds good to me, because if we just list middlewares on the site, that'll give a way for people to get their custom ones listed in the same place to be on an "equal" level to the "official" ones, which is my main concern.
all the middleware should work without connect/express anyways, so really they are all node utilities. if they don't, we should either move them out of the org or just deprecate them. (i'll add this to the readme)
the ones i listed on the readme are just the really low-level ones that any framework could use
hmmm not totally against this though. we could move it to something like http-utils or web-utils. for end users, they can just see the middleware and not the utilities they probably wouldn't even use.
+1, I think that we should do this over my original opinion.
Never thought that we we will face such a situation. Anyway it is great to make a org like this.
No-one has objected, so we will use jshttp - https://github.com/jshttp - for this unless someone objects before we start the move.
Yey