I need to create an ssh tunnel to connect to my database, so the logical point would be to add the shell command in package.json under scripts/prestart.
However, as it seems, slc run does not execute this script, npm start does, but of course doesn't run the loopback module.
I could think of a few workarounds such as writing a startup script that both creates the ssh tunnel and calls slc run, or running slc run in package.json scripts/start, but all these workarounds stink.
Is there a better way to do this?
I'm not sure how useful this is but 1 option I thought of was that if you don't really make use of slc run features you could just define your own npm start run script and hit the server script directly and add in whatever other tooling you need such as nodemon or supervisor etc.:
"start": "node server/server.js"
If you do need to use slc run, I think I would tend toward just wrapping slc run in your start script as you mentioned in your question. It kinda stinks... but not that badly.
Related
I am trying to use npm-run-all to manage running two servers at the same time. For one of the servers, I am trying to run it in a watch mode using tsc-watch.
The command looks like such:
"start": "tsc-watch --onSuccess \"node dist/server.js\""
npm-run-all starts up both of the servers successfully. tsc-watch also watches the Typescript file for changes and automatically recompiles it successfully.
However, when tsc-watch recompiles the Typescript file and restarts the server, it seems like npm-run-all stops working properly. Specifically, if I try to kill both of the servers by pressing CTRL + C in the terminal (OSX), it will only kill the server that tsc-watch recompiled while the other server remains running.
I'm thinking that there must be a way to fix this. Anyone have some tips for me?
Found an answer. I think this is just a bug with npm-run-all. Using concurrently instead doesn't experience this issue (kills both servers when hitting CTRL-C).
I have a nodejs project written in Typescript. Therefore, i have webpack using a typescript loader that transpiles my code in Javascript and bundles it in a server.js file (in a dist folder)
When in developement conditions, my webpack runs with its watcher ON and so does nodemon.
Problem is, when i launch my script for the first time combining webpack and nodemon, since webpack is in watch mode it doesn't have an exit code saying that everything is ok, nodemon script can be started. If i run them simultaneously, nodemon will launch faster than webpack and since server.js file doesn't yet exist, it will crash at the start.
I want to launch thanks to one single command both scripts but make nodemon command wait for the bundling to be done.
First of all, when please provide some code when submitting questions.
and since server.js file doesn't yet exist
I think you should work around your setup a little bit s.t. webpack doesn't create your server.js file if you want to do this.
Basically you can chain multiple commands in a script like so webpack -d && nodemon index.js. This will launch node after webpack completes. However if you setup webpack in watch mode -w it never exists, so you can't chain another command to it. So webpack -d -w && nodemon index.js never gets to the nodemon part.
A solution to the above is to chain them using only &, which I guess you are doing, but in this way they both start at the same time. Hence, if you make your setup independent (webpack doesn't interfere with nodemon starting script) you can list them like so.
If for whatever reasons you can't do this or don't want to, your only option is with 2 separate scripts that you launch manually one after the other.
If I were you, I would just use nodemon-webpack-plugin:
Uses Nodemon to watch and restart your module's output file, but only
when webpack is in watch mode (ie, --watch).
Saves the need for installing, configuring and running Nodemon as a
seperate process.
I'm writing end to end tests for an express site, and I want to add a "test" command into package.js
This command needs to:
run eslint
compile typescript
start node server
run unit tests against that server and show output.
once done testing, close the server.
I know how to execute all those commands individually, but not all at once.
What I have now is :
npm run compile && npm run build && node ./dist/server.js --db=test && npm run test
It works to the point of: "&& npm run test"
since node server is running, it won't continue on to the next command, and if it closes then tests wouldn't run.
Any help is appreciated.
One thing that I have found to help with reliable, maintainable end-to-end tests is to separate concerns:
Test suite assumes that the server is already running
Orchestrator calls into separate commands to bring up your test stack then run the tests
In CI, this could look like
npm start-e2e-test-stack --port=XXXX --db=test
npm test --port=XXXX --db=test
npm teardown-e2e-test-stack
In my experiences, having the end-to-end tests operate against any server helps to allow them to verify all environments, local, dev, qa, staging, production.
I'm familiar with debugging my own node apps (usually with node-inspector). Today I'd like to debug someone else's program. I'm trying to track down an issue with supervisor. So naturally I just add a --debug (or debug-brk) to the command call, but it passes that to the code that it is supervising.
I've tried adding debugger lines to the js file for supervisor but that didn't work (probably because no debugger was attached at that time). There's a bit of a race here -- I need to start the debugger and attach it to the supervisor process after it starts but before it processes its arguments from the command line.
What I really want to do here is stop supervisor and debug it before it processes its command line arguments. How can I do this?
I had the same problem while developing my hexo blog. The documentation isn't all that complete yet so I find myself needing to reverse engineer at times.
The basic idea is that in Node.js even your cli apps are simply normal node apps that you are exposing to the OS command line interface. On Unix systems you are using this line:
#!/usr/bin/env node
To allow the environment to execute the script.
Many cli based node apps try to insist that you install them globally with the -g option.
npm install -g node-inspector
I personally prefer to have as much control of my development environment as I can get, so I prefer to break some conventions and check my node_modules in to source control along with installing everything I can locally by dropping the -g.
npm install node-inspector
Now you don't have to do this in order to make this work, I'm just describing this setup because it relates to your question. When I run node-inspector I can't simply use:
node-inspector
Instead I must explicitly invoke it from within my project. I do this by executing the symlink in my node_modules/.bin folder:
node_modules/.bin/node-inspector
Now I'm running node-inspector just like you.
Next all I need to do is start the cli process in debug and optionally pass params to it:
node --debug-brk node_modules/.bin/hexo generate
Note I am explicitly calling the symlink here and not simply:
node --debug-brk hexo generate
If I tried the line above I would get an error: "Error: Cannot find module".
I hope this helps.
How can I run hapijs as a server deamon on a Linux box? Right now, I'm running it as a user process for development with the node index.js command for the main page, but in the long run it should be www-data or whatever else user that runs the process.
If you want to run node as a daemon without any extra tools, you can use nohup:
nohup node index.js &
However, the following tools can do this and also have some other really useful features such as automatic restart on exit, log redirection and in the case of PM2, clustering:
PM2: https://github.com/Unitech/pm2
Forever: https://github.com/foreverjs/forever
If you want your service to start when your machine start/reboots, you can use something like Upstart (on ubuntu) or System-V:
https://www.digitalocean.com/community/tutorials/how-to-write-a-linux-daemon-with-node-js-on-a-vps
To run as different user to the user you're logged in with:
sudo -u somebody node index.js
Please note that none of the above is specific to hapi but rather applies to any Node.js app.
PM2 is the best option hands down. It scales from local development through to production without issue.
First Step:
npm install -g pm2
The -g flag is simply for installing to globally so it's available as system command.
Second Step:
pm2 start index.js
The start command simply replaces node index.js Behind the scenes it runs the node process but as a daemon.
PM2 Actual Use Case
cd projects/my-app
npm install -g pm2
npm install
NODE_ENV=development pm2 start index.js -n my-app
pm2 stop my-app
pm2 restart my-app
pm2 status
pm2 logs my-app
pm2 m
Those should be enough to get you going. The nice thing about PM2 is it works great in a CI/CD environment as well since you can recall process by name. Finally out of the box it does log rotation and a few other awesome things to keep you going even if stuff goes south. Apps will also auto restart if they crash (obv. configurable).
Additional configuration allows PM2 to watch files on disk and restart the app as they change. This is great for development as you can code + save files and the API you're building in HapiJS will simply restart and your changes are live.
I use supervisord and it works great.
In short you have to configure supervisord to start your hapijs application. In addition you need to configure nginx or apache to reverse proxy requests to your hapijs application.
You can find detailed instructions on set up at http://blog.risingstack.com/operating-node-in-production/
It feels odd to suggest a tool when you haven't explicitly asked for one. nohup-ing the process and running in the background is an option that requires no new tooling, but for what it's worth, I would suggest Docker-izing the application and letting docker handle everything. Docker has several features built in, and even though it is not just for creating a daemon (it does so much more), you can use it's restart='always' feature to keep a process running.
Hope that helps.