The apps are just thin config holders and some basic harnessing. Moving some of the middleware feature to routers might be nice. I dunno, I kinda got over it when the original request was denied and just stick with the supported basics for now :D

the only reason i want to do this is so we don't have to support any sort of settings inheritance. people do use apps just as routers, but then they get the unwanted side effect of the settings not being inherited. if you want to support app inheritance, that's a different thing, but IMO it's a waste of time.

this would probably be a nicer feature for people just learning about using modular apps. However, once you get there it'd probably get in the way. I don't really use many settings inside of express except the usual dev/prod stuff just my thoughts on the matter...

if I understand you correctly, you would give the idea that app. could inherit between routers, by separating it here I think you could either cause confusion or bring out the inheritance issue again... idk?

not sure what that means. it sounds like you think routers inherit settings from apps, which is incorrect. let me try to explain this more:

right now, people do app.use(subapp) and expect subapp to inherit settings from app. i would expect this too... except when i don't want that to happen, i.e. if the subapp is an entirely different app whose settings should not be shared.

instead of adding 100 types of options to deal with these cases, it's easier just to have people mount routers like app.use(router). now the router and all its middleware's app is app. app.use(router) is just adding more middleware. any middleware that is used by app that isn't another express instance will have app's settings.

that is, there will never be inheritance when people do app.use(subapp) or app.use(router), and we will document this specifically. i think "no inheritance, ever" is an easier concept to grasp than "there's inheritance if you do this, but no inheritance when you do that".

did that clear things up? do you have any cases (in code) that you need clarification on?

not sure what that means. it sounds like you think routers inherit settings from apps, which is incorrect.

I know that, sorry to confuse -- I meant that it could imply to someone just learning that maybe it could, or would rise the argument of having that functionality introduced, which i think we all agree against.

oh, yeah. right now people will think that it could because apps do have inheritance. by explicitly documenting "there is no inheritance, ever" i think will lower the learning curve. we should also state that inheritance will never be added.

the only thing wrong with not inheriting is for settings like "trust proxy", we'll have a similar issue in koa, pretty tempting to make that an environment variable instead of propagating settings around

In my use case I need multiple routers (to serve different routes based on the hostname) and having more apps would just force me to load all the same middlewares and configuration again.
The same "problem" affects the views subsystem.

I understand it's not what the majority of the users need - but someone does appreciate an extra dose of modularity :)
As of now, I'm using express.Router and a rendering engine (consolidate.dust) directly - which is kind of hackish, but it works

I got to this thread from a search because it seemed a little odd to instanciate express again for a sub router.. then again, having a sub-method of an instance create a new child of that instance isn't really standard... what if instead of router we called it child?

of course, the existing functionality should still work, creating a router = express() and then app.use(router). I personally don't set and get a lot to the app, even though I probably should. I usually use a config handler separately.

so... Router has no method use, or set... I would like a sub app, with app inheritance. for now, I will probably find the getter/setter attributes storage and deep extend that onto the newly created express() app.

I'm probably going to build my own extender for this purpose, but it would be nice if we could treat express apps as instances of classes, which can be extended like any other class. I surely am not going to set my views up repeatedly

Right now I am leaning towards making app.use(another_app) just mount the internal router of the other app. This means that the second apps settings or other things are ignored (which is consistent with current behavior) or was the intent of this change to allow the other app to preserve its settings?

I am leading app handling/mounting another app as it. This provides a way for users to isolate views or whatever into apps if they want. For users who want the same view system/single app I will be updating the website/docs with a new "routing" section that outlines how to better leverage the more powerful Router in express 4