Move all connect middleware documentation to api#middleware.
Redirect connect docs to there.
merging of issues #13, #24, #37, #99
This seems weird to me. Connect is its own thing. Also, maybe we should just break up the various connect middleware into modules? What is the point in maintaining one giant package of middleware? It seems that the connect module should just be a middleware stack and the actual middleware can live in modules? Yes, I know we now have 20 repos where we once had 1, but we don't need to have all the issues pile up in one repo either. This might be out of scope for discussing in this issue tho.
Yeah, agree. I'm going to remove the connect proto patches so that it's possible.
i was getting sick of maintaining them separately and the connect docs look like ass haha. github readme's ftw
we're removing most of the complicated ones like multipart, so it shouldn't be difficult.
if we do this, connect won't include any middleware. which ones should we include in express, if any? i'm thinking of only including the commonly used ones that we don't considered terrible and are stable:
i don't want to include sessions because i think it needs a rewrite, but i personally don't want to do it. by not including it, i can just add people as collaborators and make breaking changes independent of connect/express and have less people be like "y u make breaking change and only do a patch bump in express?".
-1 for compress (out of scope and really why bother)
-1 for response time (what does this even do?)
-1 for error handler (should educate users on implementing their own correct one) and builtin one should just print the stack or something
-1 for body parser (isn't that going away in favor of using json and url-encoding directly?
-1 for cookie session (carries too many opinions I think)
+1 static (tho maybe separate module)
Actually I think all middleware should be separate modules and we should just require the ones we want to provide with the default distribution. Ideally those will be the ones with few opinions (things like implementing parsers, RFCs etc)
yeah, i'm asking which ones to include with express. if we don't include any or the commonly used ones, people are going to complain.
for body parser, i meant body parser + url encoded + json, since they would all be in the same repo like https://github.com/visionmedia/co-body. it's not going away - we're just telling people to use json and url encoded directory right now so they don't get those multipart warnings.
they're all going to be in separate modules. maybe not static and directory though, i think they rely on each other.
csrf without any sessions? doesn't make sense to me. cookie sessions + csrf makes sense to me, but including one without the other doesn't.
yeah, agree with the error handler and response time.
i think a lot of people use compress though.
At a minimum, we need to include at last a reference and link to the middleware that is included on the express object, at least for now, until we remove/deprecate ones that don't fit.
My most used are compress, static, json, urlencoded, but I also use errorHandler for dev.
Express 4 will not depend on connect so we will have to document any middleware we include ourselves as well as how middleware works.
removed docs in 4.x. @defunctzombie you may want to edit the copy as i wrote it out of my ass. we will need to link to static when we add it though.