I need a test.sh (bash)/test.ps1 (powershell) shell script of the following structure:
<build preparation>
npx react-scripts start
<build cleanup>
The build cleanup step should run after I stop the localhost development server.
Currently, if I send Ctrl+C to the terminal, it stops both the dev server as well as the parent script, so the build cleanup step is not executed.
I did not find similar questions online (I am not sure what to search). Preferably, I need both PowerShell and Linux solutions. My only guess is somehow the react-scripts command should "trap" the shell Ctrl+C invocation, and self-exit safely, but I do not know how to do that unless react-scripts implements it on their own.
In PowerShell you can use a try{}finally{} construct to ensure the cleanup is run on interruption:
# <build preparation>
try {
npx react-scripts start
}
finally {
# <build cleanup>
}
Related
I deployed a website (React + node.js) using a VDS (hostvds).
I installed apache 2, npm serve and npm forever.
The problem:
I can't keep alive frontend and backend at same time when i quit puTTy..
What i did to deploy the application:
-To run the backend, I use: forever server.js (using VDS console)
-To run the frontend, in /var/www/html folder, where i moved my front build folder, I use serve build (using puTTy)
Everything works perfectly, but when i quit puTTy the frontend stop to work.
Could someone tell me how to run and keep alive frontend?
Thanks
The problem you're facing is that the command you run in the front is attached to the tty and when you close the connection the command dies as well. This is not happening on the back because the forever tool detach it so it can effectively run forever. Your question can be summarized as "How to run multiple commands in detached mode?" A quick search give some results that can achieve what you are looking for, for example using screen. Yo have multiple approaches:
Op1: Using Screen
# run backend command
screen -dm "npm start"
# run frontend command
screen -dm "npm start"
Note that the screen command is used to create new sessions and detach them from the tty. So nohup could handle your issue.
and
Op2: Using systemd service
Another, and more robust way is using services of systemd and handling the lifecycle using systemctl command. In this way you can define restart policies (autorestart when failed) and also autostart when the machine reboots. You would have to create two different units, one for back and one for front.
Create the files
/etc/systemd/system/backend.service
[Unit]
Description=My backend
[Service]
Type=simple
Restart=always
User=nobody
Group=nobody
WorkingDirectory=/your/back/dir
ExecStart=/usr/bin/npm start
[Install]
WantedBy=multi-user.target
/etc/systemd/system/frontennd.service
[Unit]
Description=My frontennd
[Service]
Type=simple
Restart=always
User=nobody
Group=nobody
WorkingDirectory=/your/front/dir
ExecStart=/usr/bin/npm start
[Install]
WantedBy=multi-user.target
Once the files are created you can handle the service lifecycling with systemctl:
Run the apps:
systemctl start [backend|frontend]
Stop the apps:
systemctl stop [backend|frontend]
Check status:
systemctl status [backend|frontend]
To enable the autostart on boot just enable the service(s) using systemctl enable [backend|frontend]. You can disable it using `systemctl disable [backend|frontend].
Op3: Static frontend
Doing the options 1 and 2 will solve your issue, but have in mind you are serving a frontend using npm when it could be build to static files and served using apache2 directly, which will reduce cpu/memory consumption and it would be much faster. This is just regarding the frontend, the backend is dynamic and it needs the option 1 or 2.
As you mention it I assume you know how apache2 works, so just build the frontend application to generate plain html, css and js files, then move them to the apache2 folder and it will serve the files to the users for you.
cd /your/front/folder
npm run build
cp -r build/ /var/www/html
More info on how to build the statics here
Summary
Running commands in a shell will attach them and if you close the shell they will die unless you detach them. You can use detaching tools like screen or nohup, or you can change the approach for this specific scenario and use services to handle the lifecycle (apache2 is also a service).
Why don't you try to use forever for the front-end as well? If I remember well, the whole point of the forever service is to keep the command running even if you stop the terminal. I would try something like forever start -c "npm start".
I have a React-Go application set up in as follows:
--root -> (client & server)
Is there a way to launch both applications (npm run start & go run .) from the root directory, maybe using a shell script?
Go and React App in their subdirectiories
If layout of your project is:
root
|-client (React)
|-server (Go)
you can add shell script or Makefile to simply run both apps. Super naive shell script running two subshells, one for each component would look like:
#!/bin/bash
(cd client/ && npm start) &
(cd server/ && go run .)
Starting Go server using npm start
Assuming layout of project is something like typical React app:
root
|-node_modules
|-public
|-src
|-server (Go code)
|-package.json
|-go.mod
...
You can add your go command to package.json start command like this:
"start": "react-scripts start & go run ./server"
where ./server is path to main package of Go application. Note that it can be literally anywhere (even complete different directory or above the React app, etc.)
Running npm start will then bring up both React and Go apps.
In both cases you will have to send SIGINT (press CTRL+C) multiple times to terminate node.js and then Go app. You can overcome this by writing better shell script.
NOTE: This is only suitable for development; for production you probably want to use pre-built Go binary and both parts under proper service manager that handles crashes of either part gracefully.
I have written my react app and when I run npm start it does bring 'GENERATE_SOURCEMAP' is not recognized as an internal or external command, operable program, or batch file.. I'm using windows 10. Can someone help me with solving this?
My crystal ball says your package.json's "scripts" has something like
"start": "GENERATE_SOURCEMAP=false react-scripts start"
to set the GENERATE_SOURCEMAP environment variable, which would be fine with POSIX shells such as those used by macOS and Linux, but in Windows's command processor.
To run on Windows, you will need to get rid of the GENERATE_SOURCEMAP=false there; if you do want to set the environment variable, do it manually first.
> set GENERATE_SOURCEMAP false
> npm start
The other easy option is to add e.g. cross-env, and do cross-env GENERATE_SOURCEMAP=false react-scripts start.
I solved this by creating file .env.production and putting GENERATE_SOURCEMAP=false there... then you can simply run just react-scripts start
I run this script as startup application (ubuntu)
#!/bin/bash
npm run start
and i get error
Module.createRequire is not a function
If i run it normally from terminal - it s ok.
How can i fix it?
I am having trouble getting Jenkins to use the "npm" command from the "Execute shell" (under the "Build" step).
I am attempting to set up a new Jenkins instance (a copy from a previous one). I just imported the old jobs and am now getting the various services that these jobs depend on (e.g. maven, nodejs, ansible etc.) installed.
I am having trouble getting nodejs and npm, in particular, set up.
When I type the command "npm install" on the command line, I get the following:
uws#9.14.0 install /var/lib/jenkins/workspace . . .
. . .
Binary is fine
added 1282 packages in 36.424s
When I then attempt to run the same command using the Jenkins execute shell, I get the following:
+ npm install
/tmp/jenkins7750702649955218109.sh: line 2: npm: command not found
Build step 'Execute shell' marked build as failure
Why would this command be accessible to me from the command line but not to Jenkins?
Some things I have checked:
-The path to "node" and "npm" are both on the path. At least "shortcuts" are on the path (this worked in the previous Jenkins instance).
-The node and npm binaries have root:root ownership, but their security settings are (currently) 755 (or -rwxr-xr-x).
-I have the nodejs plugin installed. Not sure of how to use it, but its settings match those on the previous Jenkins instance. Both instances use the execute shell (as opposed to any special Jenkins tool) to run the "npm" commands, whilst only the old version worked.
So, what else should I be checking that I am not? What does Jenkins require to access the "npm" command?
Try this below options in Jenkins
Option 1:
Option 2: