expressjs.github.io
expressjs.github.io copied to clipboard
expressjs
Project migration status tracker
Going to use this to track our progress on migrating all the remaining stuff out of express core. We'll just use this repo for these things, for now I guess haha.
- [x] Router - (@dougwilson)
- [x] Docs - (@Fishrock123)
- [x] Views - (@Fishrock123)
- [ ] Settings
- [ ] req/res Prototype extension
- [ ] Application ("glue")
- [ ] Generator / Scaffold ("Wizard")
Utils should be bundled for now.
If you want to take something, mark your name behind it like: (@Fishrock123)
Note that any of this does not belong in the jshttp org, i.m.o, since that org is just a collection of HTTP utilities--we probably need a new org for the higher level things to live in, but for now it can just be expressjs.
Sounds good guys. Hoping to have some more work done on that inventory of the modules in this org soon, barely got to get started this weekend. It's a gist for now, but I'll move it in the wiki once it's got enough content to be helpful
Mike's phone
On Aug 4, 2014, at 13:11, Jeremiah Senkpiel [email protected] wrote:
Just migrate it to here for now, maybe.
— Reply to this email directly or view it on GitHub.
req/res Prototype extension
Something like this?: https://github.com/rlidwka/express-reqres
@rlidwka yep, pretty much :) Really the only differences I had in mind was tests, jumping out of the wrapped would remove the prototype extensions, and and it would inject the prototype into the existing chain rather than replacing it (all to make it must more flexible as a stand alone :) )
Well, tests are the same. It's a bit annoying to replace var express = require('../') with var router = require('./support/router') everywhere, but otherwise all req.*.js and res.*.js should work with minimal changes.
Prototype chain is the same as in express (with possibility of monkey-patching with require('express').request.__proto__ = ...). I don't know how to do it otherwise, since different requests could have different chains in theory, and actually creating new prototype for each request could be too expensive.
It's a bit annoying
lol, tell me about it. I have a repo that is just the express 4 router but I think so far 85% of the time has just been cleaning up the tests from express for it (though they will be some pretty awesome tests compared to the router tests currently in express).
ok guys I started here in a gist but realized I needed to do things a cleaner way.
So I did this: https://github.com/mikermcneil/expressjs.github.io/blob/module-list/MODULES.md
It's generated by hitting the github api to get the latest list of repos, then merging that w/ a manually-curated JSON file w/ extra metadata on the repo (this could be extrapolated/federated into each individual module's package.json eventually)
Haven't done too much of the aforementioned "manual curation" yet-- I'm going to keep going through and start putting it together, but now at least there's an automated thing, and I wanted to show you guys/get feedback/see if you had any ideas/etc.
@mikermcneil that is awesome. In fact, I know some other people were like "eh" but I though it would be cool to have a dashboard page of the modules, where it would list all the modules in a able and just have like columns of badges. Simple example of a "dashboard" page (it would be a separate page from what you're doing):
| module | version | dependencies | downloads |
|---|---|---|---|
| body-parser |  |
 |
 |
@dougwilson sorta like https://github.com/balderdashy/sails/blob/master/MODULES.md?
Can use the same templating system. I copy and pasted some of that from what I'm doing to compile Travis.yml files when stuff needs to be encrypted, so I can just publish some of those standalones. Would be trivial to make a version with build status/latest npm release badges. Happy to do that
haha, yea, though stuff like the Davis badges are the most useful to me :) The Travis badges are OK, but not completely necessary on a dashboard, since the only time it would change is if you're committing to the repo, and you should be watching Travis anyway :)
ha well travis always makes sure to find his way into my inbox- I'm sure it's no different for you guys :)
On Wed, Aug 6, 2014 at 11:07 AM, Douglas Christopher Wilson < [email protected]> wrote:
haha, yea, though stuff like the Davis badges are the most useful to me :) The Travis badges are OK, but not completely necessary on a dashboard, since the only time it would change is if you're committing to the repo, and you should be watching Travis anyway :)
— Reply to this email directly or view it on GitHub https://github.com/expressjs/expressjs.github.io/issues/7#issuecomment-51357318 .
Mike McNeil founder http://balderdash.co
http://github.com/mikermcneil C O NFI DEN TIA L i nfo rma tion in tended only for t he addressee(s). If you are not the intended recipient, empl oyee or agent responsible for delivery to the intended recipient(s), please be aware that any review, dissemination, use,distribut ion or copying of this message and its contents is strictly prohibited. If you receive this email in error, ple ase notify the sender and destroy any paper or electronic copies immediately.
I talked with @dougwilson And we are going to be moving all this migration talk, tracking and files to a it's own repo and keep this for the website.
Name ideas: expressjs/: future, migration, project, project-status, project-tracker
I prefer project-tracker.
Sounds sensible to me. In that case, want me to spit out the npm/travis badges in a table and send a PR w/ that to this repo? And I'll PR the MODULES.md stuff to wherever y'all tell me to.
Or if you want a private repo I can set up a neutral org account (happy to cover costs for that for the time being)
@mikermcneil I'd rather you sent a pr to the new repo when we make it.
It can be public, and it can just be in this ~~repo~~ org, we just need a name for it. (see above)
And you can just push to it directly :) Even to a branch if you want to be super cautious or something.
Well, tests are the same. It's a bit annoying to replace var express = require('../') with var router = require('./support/router') everywhere, but otherwise all req..js and res..js should work with minimal changes.
I'm using mockreq and mockres at the moment:
- https://github.com/balderdashy/sails/blob/master/lib/router/req.js#L6
- https://github.com/balderdashy/sails/blob/master/lib/router/req.js#L6
- https://github.com/balderdashy/sails/blob/master/lib/router/index.js#L165
Prototype chain is the same as in express (with possibility of monkey-patching with require('express').request.proto = ...). I don't know how to do it otherwise, since different requests could have different chains in theory, and actually creating new prototype for each request could be too expensive.
But I'm doing exactly that-- I guess what you guys are saying is that maybe we should have a modified version of the HTTP server that exposes a hook of some kind to allow you to modify the dna of the req/res objects that it produces?
@mikermcneil I'd rather you sent a pr to the new repo when we make it.
ah sorry I misread earlier- thought you meant this would be the project tracker (travis, etc) and the new repo would be for the migration stuff. I'm on the same page now.
I'm using mockreq and mockres at the moment
cool, through at least in our repos, we don't mock things, because it has bitten us a bunch of times in the past. I don't even mock HTTPS servers any more, instead checking in a cert and key for it to use.
have a modified version of the HTTP server that exposes a hook
naw :) I mean when you have an object in javascript, it has a prototype chain. For example, you have something like req -> IncomingMessage -> Readable -> EventEmitter. The way express currently does the replacement is to make it's prototypes chain to IncomingMessage directly, then takes the req and replaces it's chain with the express req chain. This is not very flexible and basically stomps on whatever the chain on req actually is.
The way it should work is get a request, hook the express proto to chain off the req's existing chain, then swap the req chain for this new chain. Basically, it should inject itself into the prototype chain as the first in line, rather than completely replace the chain. One benefit is that you could then compose proto modules, for instance making res.send, res.json, etc their own module and req.ip, req.protocol, etc. their own module and you can compose both together or not, as you wish.
This is the dream of the framework of frameworks :)
why not just use this repo o.O would be nice for *.github.io to be a list of modules and their badges.
we could just rename this organization so it isn't associated to express anymore. github will handle all the redirects
github will handle all the redirects
ha! redirects would be awesome to show that we as "express" moved somewhere else ;)
@jonathanong hmm maybe not for that then?
Just doug and I didn't think issues for tracking the migration (like this one) belonged here.
oh refactoring express doesn't really need a dashboard or anything complicated. that really only concerns us. i was thinking of a dashboard thing for the modules refactored out of express, i.e. the stable stuff.
@Fishrock123 for docs if it helps, the router will be landing as the npm module router :D
Speaking of redirects I can make the #express irc redirect to whatever channel we want. :p