Comments (58)
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.
from expressjs.github.io.
Just migrate it to here for now, maybe.
from expressjs.github.io.
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.
from expressjs.github.io.
req/res Prototype extension
Something like this?: https://github.com/rlidwka/express-reqres
from expressjs.github.io.
@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 :) )
from expressjs.github.io.
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.
from expressjs.github.io.
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).
from expressjs.github.io.
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.
from expressjs.github.io.
@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 |
from expressjs.github.io.
@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
from expressjs.github.io.
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 :)
from expressjs.github.io.
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
#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.
from expressjs.github.io.
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
.
from expressjs.github.io.
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.
from expressjs.github.io.
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)
from expressjs.github.io.
@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)
from expressjs.github.io.
And you can just push to it directly :) Even to a branch if you want to be super cautious or something.
from expressjs.github.io.
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?
from expressjs.github.io.
@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.
from expressjs.github.io.
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 :)
from expressjs.github.io.
why not just use this repo o.O would be nice for *.github.io
to be a list of modules and their badges.
from expressjs.github.io.
we could just rename this organization so it isn't associated to express
anymore. github will handle all the redirects
from expressjs.github.io.
github will handle all the redirects
ha! redirects would be awesome to show that we as "express" moved somewhere else ;)
from expressjs.github.io.
@jonathanong hmm maybe not for that then?
Just doug and I didn't think issues for tracking the migration (like this one) belonged here.
from expressjs.github.io.
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.
from expressjs.github.io.
@Fishrock123 for docs if it helps, the router will be landing as the npm module router
:D
from expressjs.github.io.
\o/ (I just assumed it anyways haha)
from expressjs.github.io.
oh damn niCE!!!!!!
from expressjs.github.io.
would be freaking awesome if we got all the semantic names.
from expressjs.github.io.
Speaking of redirects I can make the #express irc redirect to whatever channel we want. :p
from expressjs.github.io.
And it's thanks to @mafintosh for this one :) He was gracious to let us continue on the name.
from expressjs.github.io.
one thing though is i don't like having deprecated libraries in the org. should we have a expressjs-deprecated
org or something? lol
from expressjs.github.io.
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.
from expressjs.github.io.
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?
from expressjs.github.io.
@ChiperSoft all that may be a bit much. Perhaps a summery every hour?
from expressjs.github.io.
Yea, there are times where there are probably way too many commits, especially a bunch of force pushes.
from expressjs.github.io.
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 :)
from expressjs.github.io.
Thanks to @cpsubrian we have the npm module views
as a place to land the views subsystem!
from expressjs.github.io.
Holy shit, dude, that's awesome.
from expressjs.github.io.
Hey I came up with a name for our generator / scaffold if no one has it yet: Wizard. ;)
from expressjs.github.io.
? https://www.npmjs.org/package/wizard
from expressjs.github.io.
gandolf
from expressjs.github.io.
How do we feel about "wizard"? I can see if we can capture that one.
from expressjs.github.io.
it's not very web-centric... I mean, unless you're planning to build a generic generator tool like yo.
from expressjs.github.io.
Here's an idea: https://www.npmjs.org/package/elf
You know, like santa's workshop elf? Assembles all the toys.
from expressjs.github.io.
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
from expressjs.github.io.
are you a wizard?
from expressjs.github.io.
Have you never asked one to install software for you? Clearly we are (or could be). :P
from expressjs.github.io.
God, Doug, you don't just ask someone if he's a wizard!
from expressjs.github.io.
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 [email protected] wrote:
God, Doug, you don't just ask someone if he's a wizard!
—
Reply to this email directly or view it on GitHub.
from expressjs.github.io.
npm packages that start with node-
are kind of lame :(
from expressjs.github.io.
I just mean the code inside :)
Mike's phone
On Aug 8, 2014, at 9:28, Douglas Christopher Wilson [email protected] wrote:
npm packages that start with node- are kind of lame :(
—
Reply to this email directly or view it on GitHub.
from expressjs.github.io.
I'm going to have my hand at extracting the view engine thing, unless someone else already is.
from expressjs.github.io.
I'm going to have my hand at extracting the view engine thing
go for it :)
from expressjs.github.io.
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.
from expressjs.github.io.
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
from expressjs.github.io.
@dougwilson What is the status on expressjs/express#2218?
from expressjs.github.io.
@jonathanong would it make sense for me to put that orgs-in-repo+metadata markdown table builder thing in repo-utils?
from expressjs.github.io.
Related Issues (6)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from expressjs.github.io.