Why did the startup stub get moved to bin/www ?

[expressjs]

Why did the startup stub get moved to bin/www ?

[dougwilson]

So you can require('./app') from external files and get the express app that is not listening on any port (think unit tests and the like).

[kevinSuttle]

My system sees www as a Unix executable (yes, I see the server config JS in the source of it). Seems to be an odd convention to adopt, no?

[defunctzombie]

No. It is not odd.
On May 8, 2014 9:16 AM, "Kevin Suttle" [email protected] wrote:

My system sees www as a Unix executable. Seems to be an odd convention to
adopt, no?

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

[kevinSuttle]

Helpful.

Care to elaborate?

[jonathanong]

you'd want to separate your app logic and actually running your app. for development, /bin/www is the basics to get things going. but in production, you'd really want to use something more robust like https://github.com/unitech/pm2 and https://github.com/koajs/cluster for error handling, clustering and load balancing, etc. each app has its own best way of doing it

[kevinSuttle]

Right, which validates my original comment of it being an odd convention, if it's per application. Tomato, tomahto. ¯\_(ツ)_/¯ 

[jonathanong]

How is it an odd convention? the more important aspect is separation, but it's nice to run the server without typing node

[victorwoo]

Why is it nice to run the server without typing node?
Is there any difference between "node app" and "npm start"?

[jonathanong]

if you distribute your app as my-app, you can then do npm i -g my-app; my-app

[dougwilson]

FYI everyone, the generator is supposed to demonstrate good practices. If you don't agree with how the generator works, you don't have to use it. The point of the generator is to generate an app base for you that follows good practices with npm and the build tools.

[victorwoo]

Yes, I'm thinking about what's the better practice.
It seems a linux like path and can't cross platform. I think if it's better to separate shell script part and JavaScript part into individual files? e.g:

./bin/www:

#!/usr/bin/env node www.js

./bin/www.cmd:

node.exe www.js

.bin/www.js:

var app = require('../app');
app.set('port', process.env.PORT || 3000);

[dougwilson]

It seems a linux like path and can't cross platform.

Just because there is a shebang file, doesn't make in linux-only. You can run it on Windows using node bin/www, but really you should just use npm start. The bin/www is a valid JavaScript file node.js can run.

This will work just fine when you publish your app to npm and npm install -g it, because npm will wrap that bin/www script into a .cmd file on Windows.

[victorwoo]

OK, @dougwilson , thank you for your help!

[igor10k]

I was just wondering what's the best practice to use this new startup style with something like Socket.io 1.0 that needs an instance of http.Server()
What I ended up is something like

var server = require('https').Server(httpsOptions, app);
io = require('socket.io')(server);
app.listen = function () {
    return server.listen.apply(server, arguments);
};

It works but it looks dirty.

[dougwilson]

@igor10k make a file named like io.js in the root and export the io server. Then in www, require it (like how app.js is required) and glue them together.

io.js:

var io = require('socket.io')() // yes, no server arg here; it's not required
// attach stuff to io
module.exports = io

bin/www:

#!/usr/bin/env node
var debug = require('debug')('{name}');
var app = require('../app');
var io = require('../io');

app.set('port', process.env.PORT || 3000);

var server = app.listen(app.get('port'), function() {
  debug('Express server listening on port ' + server.address().port);
});

io.attach(server);