pillarjs / discussions Goto Github PK

renamed this repo to discussions and forked badgeboard to pillarjs. realized afterwards that i could've just pulled from badgeboard, but whatever. nice to have "forked from" at the top left.

there's no need to migrate issues just yet, but we should open new ones in pillarjs.github.io like we do with jshttp and eventually delete this repo

Hi @pillarjs/owners , I'm working on auditing the current owners of the pillarjs organization. If any of you think you don't need to actually be an owner, please let me know as a comment here or by email and I can remove you (I also think you have the ability to remove yourself).

I'm also going to be demoting the current owners that do not have 2FA on their GitHub account to just members of the organization for now. If you are affected, and want to be promoted back to an owner, please let me know 1) that you have setup 2FA on your GitHub account or 2) why you can't enable it (perhaps there is a legitimate reason).

Started with some conversation here: pillarjs/router#14 (comment)

Express, Sails and Nighthawk are all doing something similar, creating instances of Request and Response to pass to the router. Currently Express extends directly from http.IncomingResponse which doesn't work for the context of WS requests or browser routing.

The discussion I would like to have here is "How can we create stand-alone modules that can be used for all three use cases?".

cc: @mikermcneil @felixfbecker

this is a broad issue for any session stuff. i'm thinking that for sessions, it's too difficult to make a generic one (i.e. connect's session sucked). instead, we could have specs and maybe a test suite for session middleware/objects.

jshttp/jshttp.github.io#26
jshttp/jshttp.github.io#29

Basically ported express stuff that will be built in for now but that no-one will have to even include.

@dougwilson What's the progress on this? I'm not so sure how this will all work, but if I have an idea I can get working on the docs.

Extract the express router to here.

(Work is underway)

Extract the view engine abstraction from express to here.

(Work is underway)

i think @dougwilson and i discussed a querystring parser/stringifier that is more configurable and strict. specifically, i only ever want strings. haven't looked at the issue right now.

jshttp/jshttp.github.io#13

jshttp/jshttp.github.io#23
jshttp/jshttp.github.io#17

like path-to-regexp, but with trie routing instead: https://github.com/jonathanong/routington

like to move it in here :D

https://github.com/expressjs/ssl-redirect

aye or naye? might be useful in frameworks when users want ssl only.

I was wondering what people think about adding middleware like this to this org?

I built this because of a need I had, but it is similar to something that Fastify supports directly, so I thought it would be good if express had one as well. I haven't published it yet, and I was thinking that if we liked it we could publish under the @express scope.

I would also love feedback on the module itself. It is still a work in progress, but if anyone sees any glaring problems, or better api I could adopt, I would like to hear it.

Another nice module to have would be the settings management that express has:

app.set('foo', 'bar');
app.get('foo') // bar

For the things that express specifically defaults or modifies, for example query parser, I was thinking of just adding a setter registry:

app.setter('foo', function (val) {
  return 'foo' + val;
});
app.set('foo', 'bar');
app.get('foo') // foobar

My main use case here is to also share this functionality to my front end implementation as talked about here: wesleytodd/nighthawk#5

Thoughts feedback?

Various modules support callbacks or promises.

finalhandler is callback, csrf is both and templation is promises.

I'd be nice if jshttp & pillarjs consistently support either all promises, all callbacks or all both.

I'd personally recommend that we try to support both, i.e. you SHOULD support both and MUST support callbacks.