Q: "node app.js" doesn't work after "grunt build" command

[mescalito]

thanks for your time! I'm new using yeoman so i don't know what is exactly going on .

When using the grunt build command everything seems to works fine and the "/dist" folder is generated ok, but why the node app.js command doesn't fully work inside the "/dist/server" folder?

To make my app working on the "/dist" folder I have to open file app.js and then in like no.8 change 'development' into 'production'

File app.js line no.8

process.env.NODE_ENV = process.env.NODE_ENV || 'development'; // change 'development' to 'production'

• Do I need to do make that change every time I plan to deploy to the server?

After digging into the grunt.js I realized I can run this command grunt serve:dist and then the server seems to work fine, but obviously I won't have that option into my production server, I just want the "/dist" folder.

• What am I doing wrong? and how can I run my project from the "/dist" folder on my production server?

[JaKXz]

This generator has two deploy options built in: openshift and heroku. The best thing to do would be to add targets to buildcontrol task if you're using a different service, e.g. azure.

[thomporter]

On the production server you need to setup your environment properly. There are a lot of ways to do this, depending on what type of server you're on. @JaKXz has it right if you're using that kind of service. I'd also add that if you're just trying to get it to run from your development server, you might try running it like this:

NODE_ENV='production' node server/app.js

That will set the NODE_ENV environment variable to production just for the one run - fine for testing, but not how you want to be starting your server in production (at least not by hand.)

If you're deploying to a stand-alone linux box (perhaps a VPS) then I have a blog post that describes how I recently deployed a project built by this generator to an Ubuntu VPS.

[mescalito]

Thanks @JaKXz , Indeed the Heroku build-control is working fine and it does a good job (yo angular-fullstack:heroku), now I can see my app on heroku. great!

But again my question is how can I run my project from the "/dist" folder on my production server? I'm using an Amazon Server (EC2).

1. Do you mean that I will have to always use the build-control (grunt buildcontrol:heroku) to commit to my server?
   or
2. am I required to use the idea @thomporter suggested about the init file?

#!/bin/sh

export PORT="4000"
export NODE_ENV="production"

/home/tporter/.nvm/v0.10.31/bin/node /home/tporter/dist/server/app.js

I find crazy that deploy the "dist/" folder to the server won't work, or the crazy one is me?

[thomporter]

@mescalito check out #501. There's good info in there about using forever on ec2, but you'd still need to use upstart to get it to start when the server reboots. monit would not be required if you use forever.

[Awk34]

@mescalito I too would expect running grunt build and then node app out of the dist folder to properly start the express server and am having the same problem.

[kingcody]

@mescalito, @Awk34 there are two way that are very simple to use when deploying a built project locally:

1. run grunt serve:dist from you main project folder. That will build the project and serve it out in one command.
2. run grunt build then NODE_ENV='production' node dist/server/app.js like @thomporter suggested

The main thing to point out is the NODE_ENV='production' environment variable that is set when you are running a 'built' project. BTW, if you are in the dist folder you can just run NODE_ENV='production' npm start

Hope that gets you guys going :)

[mescalito]

I think the "dist/" folder must be deployable. period!

I find very stupid that I can't just commit and deploy the "dist/" folder under my discretion just because I have to go and work my way around the stupid NODE_ENV variable on dist/server/app.js

I love you so much but please stop being intrusive over my "dist/" folder, what ever happen beyond that is not your concern, Everything Yeoman does is amazing but the helicopter mom behavior is stepping beyond your responsibility.

Your build-control for Heroku and the other is great but there is more than that out there and we can depend on build-control to deploy to every fricking cloud.

PLEASE!!! Just give me a deployable "/dist" folder, or what is your excuse?

[remicastaing]

The "excuse" is with one build you can produce a dist/folder that works for production, test, staging, etc... for multiple instances, etc...
After you have set up your ec2 instance(s) with the proper ENV variables, you can deploy, redeploy, undeploy... without having to worrying if your app will you the right FB clients ID, the right DB connexion, etc...
If you want to deploy just one app, one time on a unique ec2 instance, it seems like overkill. But if you start to play with PaaS, multiple instances or have greater plans, ENV variables are a good solution.

[JaKXz]

As mentioned, there is a working recipe in #501, so I'm going to close this issue as well and welcome a PR for the grunt-ec2 task.

[DaftMonk]

I think we should make the server launchable into development mode from the dist folder without setting the node environment. It would be very easy to do: just rename the references to the public folder to client in both the express config and the grunt file.

You still should be starting your app environment to production mode when its deployed, but it would make it a little easier to test out.

[mescalito]

@remicastaing in that way you should be able to config what you are talking about (multiple instances) from the grunt file. For my having a ENV file for each cloud-server is over kill. I prefer to use multiple GIT branches and merge master into. The problem is that the Generator doesn't know where to stop and what is the line where their job ends.

[kingcody]

@mescalito I see what you are saying, however there are others who think that the generator should do more; this is likely not an easy debate.

Also I understand that in your case the style of this generator has inconvenienced your workflow. If you don't mind, could you describe to me (and others) what you see as an acceptable solution for configuring your app's settings?

I'm hoping we can work together to possibly find a way that meets your needs and those of others. I like it when everybody wins :)

Thanks for the feedback.

[remicastaing]

I was thinking of filling some infos on client side during the build process (cf. #605). Perhaps the same principle could be applied for @mescalito need.
We could use an additional config file to replace id, secret, etc... in server/config/environment/index.js:

facebook: {
    clientID:     process.env.FACEBOOK_ID || 'id',
    clientSecret: process.env.FACEBOOK_SECRET || 'secret',
    callbackURL:  (process.env.DOMAIN || '') + '/auth/facebook/callback'
  },

during the build process.

[kingcody]

@mescalito I noticed how you use GIT to manage your different configs(?) thats a really good use of git I think :)

I'm wondering how you typically deploy a node application? Something like this: node some_entrypoint.js or do you use npm like this: npm start?

[mescalito]

@kingcody Before finding Grunt I used multiple GIT branches to manage all my servers (production, staging, testing, etc). Each branch has its own config/ENV file independently with the DB, oAuth, etc. information and the proper "gitignore" file.
When deploying we just had to choose the server destination from GIT-remote and that was all on the client side. On the server side a "forever start app.js" will run the server after a GIT-HOOK (post receive) made the suitable configuration.
Now I expect Grunt make the "server side" work to avoid the scattered configuration on each server, in other words I want to centralize (if possible) everything in the Grunt file.
What I see on the generator is the lack of documentation/comments inside the Grunt.js file. The file is really complex as you have it and it will be great to dig into in order to find answers.

@remicastaing I had no idea the existence of the \server\config\environment files, thanks. How can I tell Grunt to use production.js when grunt serve/dist?

[Tom2277]

I just can't figure out how to get the app to set environment variables in production mode.

I've read a lot here and tried a lot. Somehow editing my .bash_profile (or something else?) managed to set my FACEBOOK_ID and secret to their api keys, and the NODE_ENV to production using a bash method described in #501 but the same method doesn't work for TWITTER_CONSUMER_ID or DOMAIN... (although somehow my app seems to be getting the domain accurately in another way). IF I hard code my Twitter API's into the ./config/environment/index section as the default value, my Twitter Oauth is working pretty well.

I'm just not sure what I'm missing ... I tried using require('.config/local.env') at the beginning of app.js as kingcody suggested in #513 but it didn't work.

I guess I'd just like to be able to set api keys and stuff from a .env file . I'm fairly(very) clueless on what happens if a web site starts getting traffic and requires multiple instances and unsure about whether I should be setting environment variables for each instance vih bash or shel or etc or if having them in a file (not tracked on a cloud git repo) is better ??

Thanks for any help. FWIW , I'm grateful for the generous work you guys have shared with AFS . I'm also satisfied enough with creating a production dist file with grunt serve:dist on my laptop and then cutting and pasting the files into a local "dist"-only repo where I can edit a few things then push. (I bet I could get rid of a lot of dev dependencies that are still getting included in dist huh? )