Express 4.0

[jonathanong]

Backwards incompatible changes. Woo!

• Remove express(1) move express(1) to a separate repo #1820
• Remove app.configure consider removing app.configure() #936
• Change req.params to an object change req.params to an object instead of an array #1835
• Remove/fix res.location() relative paths incorrect relative paths with res.location #1804
• Remove res.locals(obj) res.locals not made available to hjs template #1833 change res.locals to a plain js object. #1908
• Make app[VERB] each its own middleware remove app.router and refactor middleware processing #1909
• Remove dependency on connect
• Fix this error in node 0.11:
• Remove app inheritance/revisit mounting app and what this means. Right now it is too confusing and not documented. Remove app inheritance, encourage using multiple routers instead of mounting apps #1843
• Lazy cookies Lazy cookies #1139
• View middleware/module (allows for view engine as middleware)

[defunctzombie]

What does the new cookie lib buy us? Any cookie parsing changes we should
be aware of?
On Nov 29, 2013 8:57 PM, "Jonathan Ong" notifications@github.com wrote:

Backwards incompatible changes. Woo!

• Connect 3
• Remove binary move express(1) to a separate repo #1820move express(1) to a separate repo #1820
• Remove app.configure consider removing app.configure() #936consider removing app.configure() #936
• Change req.params to an object change req.params to an object instead of an array #1835change req.params to an object instead of an array #1835
• Remove/fix res.location() relative paths incorrect relative paths with res.location #1804incorrect relative paths with res.location #1804
• Lazy cookies i.e. https://github.com/jed/cookies Lazy cookies #1139Lazy cookies #1139
• Remove res.locals(obj) res.locals not made available to hjs template #1833res.locals not made available to hjs template #1833

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1838
.

[jonathanong]

not sure. just saw that issue. i'm not totally sure how cookies in express work right now.

for one, we're going to move to jed/cookies in connect instead of doing our own cookie parsing and signing.

[tj]

yeah i wanted to move from res.cookie(key, val) to using jed's stuff with res.cookies.set() and so on like koa so we can delegate key handling blah blah

[defunctzombie]

Is there an advantage to that type of api change? res.cookie always seems simple enough to me. Does it not do something currently? Or was this more cosmetic?

[jonathanong]

https://github.com/jed/keygrip for one, which i like.

[defunctzombie]

What does one have to do with the other?

That sounds like a cool lib tho.

On November 30, 2013 at 2:18:37 PM, Jonathan Ong (notifications@github.com) wrote:

https://github.com/jed/keygrip for one, which i like.

—
Reply to this email directly or view it on GitHub.

[tj]

for setting it doesn't really matter, we could retain that but for getting the lazy .cookies.get() is nice

[nook-scheel]

"Remove app inheritance" - please don't remove. I use them in the separation modules.

[jonathanong]

can you explain what you're doing in #1843 and how you can't just use routers instead?

[jonathanong]

for routing, we're going to go with this: https://github.com/expressjs/routification. it'll wrap the express prototype and we'll have to do some fixing to work with settings and .get() overload. should be backwards compatible except for app.use(app.router).

• no more implicit app.use(app.router), which is half of express' support issues
• each route is its own middleware
• you can use the router without express, but express will expose it as var router = express.router() since it has to require() it anyway
• much fewer LOC in total
• best of all, separate repo

will close: #945 #1835 and half of #1843

[mikermcneil]

Thanks for the advance notice, guys.

[defunctzombie]

Are we working on this in a branch somewhere?

[jonathanong]

Not yet. Was going to do connect 3 first. Did you want to start now?

[defunctzombie]

Yea, I was thinking of taking down some of the super trivial stuff like app.configure

[jonathanong]

Sounds good to me. I'll start doing some connect 3 stuff

[jonathanong]

do you want to just release connect 3 and express 4 asap? i wanted to wait until node 0.12, but it's taking too long. still want to drop 0.8 support, though.

[defunctzombie]

I am in no particular hurry. I wouldn't wait on 0.12. fixing 0.11 support
would be good tho. I think we can just work on the things we know we wanna
do.

On Wed, Jan 1, 2014 at 6:15 PM, Jonathan Ong notifications@github.comwrote:

do you want to just release connect 3 and express 4 asap? i wanted to wait
until node 0.12, but it's taking too long. still want to drop 0.8 support,
though.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1838#issuecomment-31432522
.

[jonathanong]

3.x is its own branch now.

@defunctzombie although i made routification, which is more inline with @visionmedia plans for v4, i'm going to let you handle all the routing and performance stuff :)

[defunctzombie]

So master is 4?
On Jan 3, 2014 5:53 AM, "Jonathan Ong" notifications@github.com wrote:

3.x is its own branch now

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1838#issuecomment-31516022
.

[jonathanong]

Yeah

[defunctzombie]

I would also like to look at making app.route() a thing. I can't find the issue right now but it was brought up as a way to make it easier to add multiple METHOD handlers onto a route without repeating yourself.

[defunctzombie]

Is there an issue for "Remove app inheritance"? What does that mean?

[jonathanong]

like when you do express().use(express()) people expect some options to be passed along. ideally, there should be a router without the proto and app stuff that people can mount that won't encapsulate settings and stuff.

basically, it would just mean removing this stuff: https://github.com/visionmedia/express/blob/master/lib/application.js#L57

[defunctzombie]

Ah. Gotcha. My new router stuff replaces the need for mounting apps.
Routers are the new hotness to create. So really all that stuff could go
even.
On Jan 24, 2014 8:08 PM, "Jonathan Ong" notifications@github.com wrote:

like when you do express().use(express()) people expect some options to
be passed along. ideally, there should be a router without the proto and
app stuff that people can mount that won't encapsulate settings and stuff.

basically, it would just mean removing this stuff:
https://github.com/visionmedia/express/blob/master/lib/application.js#L57

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1838#issuecomment-33276480
.

[defunctzombie]

@jonathanong @visionmedia anything off this you guys want to accomplish? https://github.com/visionmedia/express/wiki/4.x-roadmap

The only thing I would think about is the __express stuff. Seems like we can make it so that just require('jade') should work.

[jonathanong]

http utility methods. i'll go over the prototype later to see if there's more we can refactor. a lot of it was content negotiation though which i've already refactored.

view system could be extracted. i know people create subapps just for the view system. could be something like https://github.com/visionmedia/co-views

Seems like we can make it so that just require('jade') should work.

i mean we could, but then there would be support issues coming when something breaks :/

[mikermcneil]

@jonathanong very cool :) would be awesome to be able to use the router as a standalone module as well- I'd be down to help with that if I could

[defunctzombie]

extracting view system could be useful. That way you could .use a particular view system in separate Routers. Just have to be mindful to replace the .render back. And just like the Router there would be a default one setup in the express app.

[hacksparrow]

"Remove dependency on connect"

How do we plan to accomplish this?

[defunctzombie]

@hacksparrow most of the major work was done in PR #1909 The rest is just a matter of making repos for the various middleware we care about that is still in the connect module and using those modules separately.

[hacksparrow]

Thanks, that explains it.

[defunctzombie]

I am now working on the final pieces (view system as middleware). Once this is complete, the codebase will go into feature freeze for 4.0 documentation and release. If you would like to see any other major things implemented for 4.0 now is the time to speak!

[glenjamin]

With express not depending on connect, and connect not including middleware, is there a discussion somewhere where I can read up on the rationale of how/why a project should choose to build on express 4 vs connect 3?

The express changes look great btw, simplification + more modules sounds good to me :)

[defunctzombie]

@jonathanong I worked on making the view system just another middleware however ran into one issue exposed by the following example:

app.use(views);
app.use('/foobar', routes);
app.use(function(err, req, res, next) {
  res.render('error');
});

routes.use(views2);
routes.get('/blah', function(req, res, next) {
  next(new Error('foobar'));
});

Imagine that views is some function that patches res with a render function. The problem here is that after views2 middleware patches with its own function, the error handler res.render call will no longer render what the user wants to render. There is no good automatic way to reset back to the correct res.render method for the user. This might be a show-stopper for view middleware.

[jonathanong]

i don't think it shoudl be middleware, just a library. something like https://github.com/visionmedia/co-views. the default .render() function will be an instance of this. overwriting and rewriting propertyies is no bueno

var render = new View({
  ext: '.jade',
  engine: 'jade',
})

app.use(function (req, res, next) {
  render('home', res.locals, function (err, html) {
    if (err) return next(err)
    res.send(html)
  })
})

so if people want complicated view systems or apps just for views, they can use the lib instead.

[defunctzombie]

This makes rendering much harder on the user. res.render is very convenient and is one of the major benefits express provides over just routing.

[jonathanong]

@glenjamin expressjs/expressjs.com#113 it grew out of our own laziness, but it does make sense

[jonathanong]

well it's up to you. i don't believe in coupling view systems to apps or routes - they should be completely independent. but yeah, it is less convenient, especially if you remove encapsulation.

[mikermcneil]

We have this same problem with our res.view() method- it's pretty annoying, but dunno if it's unworkaroundable. Along the same lines, user middleware could override other core res methods like json, right? I may not understand the complete problem here, but as an express user, I wouldn't mind being told not to install multiple view-rendering middleware. Just my 2 cents :) Great work, fellas.

Mike's phone

On Feb 22, 2014, at 17:42, Roman Shtylman notifications@github.com wrote:

@jonathanong I worked on making the view system just another middleware however ran into one issue exposed by the following example:

app.use(views);
app.use('/foobar', routes);
app.use(function(err, req, res, next) {
res.render('error');
});

routes.use(views2);
routes.get('/blah', function(req, res, next) {
next(new Error('foobar'));
});
Imagine that views is some function that patches res with a render function. The problem here is that after views2 middleware patches with its own function, the error handler res.render call will no longer render what the user wants to render. There is no good automatic way to reset back to the correct res.render method for the user. This might be a show-stopper for view middleware.

—
Reply to this email directly or view it on GitHub.

[glenjamin]

I like @jonathanong's idea about just using modules.

From a user point of view, being able to use() view middleware might be confusing if only one is allowed.

You could set the middleware up to throw an exception if res.render is already defined, and point the user to some docs about views-as-functions.

You could also create a multiview middleware which does the extension checking and delegates to other view middleware if multiple view systems via res.render is desired.

[defunctzombie]

The view system will remain tied to the app and will not become middleware (too involved). However this does make me a bit sad in that I was hoping to allow subapps/routers to have their own views if they wanted (something currently not supported) but the more I think about it, the more I think this is a hard approach to pull off realistically. The way express is written, an app is meant to be a single instance which contains some settings and sets up a view system. To this end, I think that even allowing for "mounted" apps is now incorrect and will only cause confusion because none of the app settings or even the app view system will work the way someone would expect when they create this subapp and mount it. For route separation, we have a very good Router. I would like to hear form people currently using "subapps" to see if Router would somehow not serve those needs.

[jonathanong]

I still think a separate lib for views is the way to go. Are you going to move the router to its own repo?

We can always release an alpha version and see how people react

[mikermcneil]

I'd love to be able to use the router as it's own module

Mike's phone

On Feb 23, 2014, at 17:05, Jonathan Ong notifications@github.com wrote:

I still think a separate lib for views is the way to go. Are you going to move the router to its own repo?

We can always release an alpha version and see how people react

—
Reply to this email directly or view it on GitHub.

[defunctzombie]

Router could be own repo. Routification repo? or do you have plans for that codebase?

[jonathanong]

nope no plans. you can use it.

[Pontusfa]

$npm update
->
/home/pontus/node/yatt/lib/init.js:60
app.use(express.compress()); // ?
^
TypeError: Object function createApplication() {
var app = function(req, res, next) {
app.handle(req, res, next);
};

mixin(app, proto);
mixin(app, EventEmitter.prototype);

app.request = { proto: req, app: app };
app.response = { proto: res, app: app };
app.init();
return app;
} has no method 'compress'

Couldn't one expect a warning about these backward incompatible changes, much like the bodyParser warning?
Reverting back to 3.4.8 and staying there I suppose.

[dougwilson]

@pontusen A change from 3.x.x to 4.x.x is basically a guarantee your stuff will break. npm uses semantic versioning for modules. You should be sure your package.json is asking for the right version of express you need (and hopefully not set *).

[jonathanong]

since all the checkboxes are checked and rc1 is out, i'll close this issue. any 4.x issues should be new issues :D

[rlidwka]

npm uses semantic versioning for modules

npm uses semver-looking versions, nothing more than that.

The choice of using semver is up to a package maintainer, and there are different schools of thought.

[dougwilson]

@rlidwka npm literally uses a dependency named semver in it's source to check versions against each other, refers to versions as "semver strings" in the documentation, and the semver module it uses (https://github.com/isaacs/node-semver#versions) states that it is

A "version" is described by the v2.0.0 specification found at http://semver.org/.

I'm not sure how much more npm can hammer in that the versions are supposed to follow semver. Also, the twitter post you linked to is exactly what I had said: "majors = b/c breaks for everyone"

[defunctzombie]

No longer relevant to this issue. Please take it elsewhere. I dont want to
get 50 emails about semver now :)
On Mar 5, 2014 3:22 PM, "Douglas Christopher Wilson" <
notifications@github.com> wrote:

@rlidwka https://github.com/rlidwka npm literally uses a dependency
named semver in it's source to check versions against each other, refers
to versions as "semver strings" in the documentation, and the semver module
it uses (https://github.com/isaacs/node-semver#versions) states that it is

A "version" is described by the v2.0.0 specification found at
http://semver.org/.

I'm not sure how much more npm can hammer in that the versions are
supposed to follow semver. Also, the twitter post you linked to is exactly
what I has said: "majors = b/c breaks for everyone"

Reply to this email directly or view it on GitHubhttps://github.com//issues/1838#issuecomment-36788763
.

[mikermcneil]

@defunctzombie Were you interested in helping pull the router out? I'm down to take the lead on that if you want to team up.

@defunctzombie @jonathanong To avoid cluttering things up and notifying a bunch of people who aren't interested in this feature, I just created a new issue. Before I jump in, would you mind passing along your thoughts? (I want to make sure the PR I work on is something y'all are cool with.) I jotted down some quick questions there.

[Raynos]

@mikermcneil you can already use the router on it's own. routes.js was broken out of connect 3 years ago.