You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Obviously ppl are encouraged to use whatever build/config approach they like the most (Grunt/Gulp/Broccoli/Make/Jake/Cake/sh/npm run/whatever + nconf/package.json/config.json/config.js/.env/whatever). For Ezel I want to keep it as basic as possible. I think keeping all config in environment variables is a good idea and using a config.js file makes it easy to accidentally require on the client-side.
So I'm sold on all config being in a .env file & preferably checked out of the repo. Using a .env loader is a decent approach but not so nice for running scripts outside of your web server which can get a little messy.
Foreman is kinda to best tool for this setup b/c a Procfile can take the place of the Makefile (hmm actually maybe not b/c it seems like foreman start tries to run all tasks), it loads the .env file automatically, and it makes it easy to deploy to the most popular PAAS—Heroku. It keeps the .env file loading outside of your scripts so you can easily run foreman run migrate. Downside however is mainly that globally installing Foreman makes it a not so nicely self-contained project or the default way to run tasks out of the box is an ugly node_modules/.bin/foreman run start—although I guess that could be mitigated by npm startnpm test. It also adds a Procfile to your app which is just awkward to rip out for hosting on other popular PAAS like Nodejitsu/OpsWorks.
I guess in the end I believe a .env file for config is a good opinion to encourage but the build tool I could care less about. It might be best to just drop the Makefile b/c it can throw the grunt/gulpers off and use npm run instead. Then clearly state that build/config is totally up to you but if you want Ezel's advice use Foreman and modularize complex build tasks into /lib or extracted node modules.
The text was updated successfully, but these errors were encountered:
rant
Obviously ppl are encouraged to use whatever build/config approach they like the most (Grunt/Gulp/Broccoli/Make/Jake/Cake/sh/npm run/whatever + nconf/package.json/config.json/config.js/.env/whatever). For Ezel I want to keep it as basic as possible. I think keeping all config in environment variables is a good idea and using a config.js file makes it easy to accidentally require on the client-side.
So I'm sold on all config being in a .env file & preferably checked out of the repo. Using a .env loader is a decent approach but not so nice for running scripts outside of your web server which can get a little messy.
Foreman is kinda to best tool for this setup
b/c a Procfile can take the place of the Makefile(hmm actually maybe not b/c it seems likeforeman start
tries to run all tasks), it loads the .env file automatically, and it makes it easy to deploy to the most popular PAAS—Heroku. It keeps the .env file loading outside of your scripts so you can easily runforeman run migrate
. Downside however is mainly that globally installing Foreman makes it a not so nicely self-contained project or the default way to run tasks out of the box is an uglynode_modules/.bin/foreman run start
—although I guess that could be mitigated bynpm start
npm test
. It also adds a Procfile to your app which is just awkward to rip out for hosting on other popular PAAS like Nodejitsu/OpsWorks.I guess in the end I believe a .env file for config is a good opinion to encourage but the build tool I could care less about. It might be best to just drop the Makefile b/c it can throw the grunt/gulpers off and use
npm run
instead. Then clearly state that build/config is totally up to you but if you want Ezel's advice use Foreman and modularize complex build tasks into /lib or extracted node modules.The text was updated successfully, but these errors were encountered: