Project migration status tracker
Fishrock123 opened this issue · comments
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.
- Router - (@dougwilson)
- Docs - (@Fishrock123)
- 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.
Just migrate it to here for now, maybe.
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 notifications@github.com 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 <
notifications@github.com> 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
#7 (comment)
.
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
\o/ (I just assumed it anyways haha)
oh damn niCE!!!!!!
would be freaking awesome if we got all the semantic names.
Speaking of redirects I can make the #express irc redirect to whatever channel we want. :p
And it's thanks to @mafintosh for this one :) He was gracious to let us continue on the name.
one thing though is i don't like having deprecated libraries in the org. should we have a expressjs-deprecated org or something? lol
should we have a expressjs-deprecated org or something?
this sounds reasonable to me. it's always possible we could revive them in some way later as well, but at least they won't be around with the others, being all confusing. GitHub should totally add tags or something for repos in orgs.
While these migrations are happening, would it be possible to setup the webhooks for the active repos so that commits and issues/comments show up in the irc channel?
@ChiperSoft all that may be a bit much. Perhaps a summery every hour?
Yea, there are times where there are probably way too many commits, especially a bunch of force pushes.
Ok, well, for pushes it could be summarized. I'm mostly interested in issues, since you guys tend to use these things like chats anyway, and I'd rather see it in irc than my inbox :)
Thanks to @cpsubrian we have the npm module views as a place to land the views subsystem!
Holy shit, dude, that's awesome.
Hey I came up with a name for our generator / scaffold if no one has it yet: Wizard. ;)
gandolf
How do we feel about "wizard"? I can see if we can capture that one.
it's not very web-centric... I mean, unless you're planning to build a generic generator tool like yo.
Here's an idea: https://www.npmjs.org/package/elf
You know, like santa's workshop elf? Assembles all the toys.
Well, node is kinda a web-server software, mainly. And installers used to be called "wizards", and quite frankly, I think it fits with how "magic" this entire build-your-own-framework might seem. :3
are you a wizard?
Have you never asked one to install software for you? Clearly we are (or could be). :P
God, Doug, you don't just ask someone if he's a wizard!
I've got this thing that works well https://www.npmjs.org/package/node-generate
Could work off of that
Mike's phone
On Aug 7, 2014, at 22:06, Jarvis Badgley notifications@github.com wrote:
God, Doug, you don't just ask someone if he's a wizard!
—
Reply to this email directly or view it on GitHub.
npm packages that start with node- are kind of lame :(
I just mean the code inside :)
Mike's phone
On Aug 8, 2014, at 9:28, Douglas Christopher Wilson notifications@github.com wrote:
npm packages that start with node- are kind of lame :(
—
Reply to this email directly or view it on GitHub.
I'm going to have my hand at extracting the view engine thing, unless someone else already is.
I'm going to have my hand at extracting the view engine thing
go for it :)
I thought somebody had already started on that. Someone showed me a repo that was in progress, maybe @defunctzombie?
edit: never mind, I was thinking of templation.
So I've been running into this semantics issue while porting the view engine.
var views = require('views')
// so lets make some views
var views = views()
// umm
var view = views()
// but it's not just one??
var ??? = views()
// yeah@dougwilson What is the status on expressjs/express#2218?
@jonathanong would it make sense for me to put that orgs-in-repo+metadata markdown table builder thing in repo-utils?