Serve is a library that allows you to serve your React build folder similar to npm start
Create an app with npx create-react-app .
Then run the following the following to create build and serve the app
npm run build
npm install -g serve
serve -s build
It works perfectly, only how does one kill the listening on port 5000
control c brings back the suspended terminal prompt and lsof -iTCP -sTCP:LISTEN -n -P indicates that it is no longer listening on port 5000.
pkill -9 node does not do it.
Even though it appears not to be listening on port 5000 I can go to localhost:5000 and it serves up the file as though it were listening on 5000;
NOTE: this happened on MacOS
The reason you're still seeing content even after the server is killed is because you're using a Service Worker. Service Workers will cache content so that even when a user is offline, they can continue to use your web app. What you're experiencing is the intended functionality.
You can make your life a little easier by using Incognito Mode when working with service workers, so you can easily reset your browser and thereby clear any active service workers.
I'd recommend you read more of the Workbox documentation as I can see you're working with that framework.
Another way to stop a service worker is through the Chrome Dev tools panel.
Related
I'm SSHing into a linux shell for a school project. Right now, we're trying to set up a react app for a web frontend. We were able to run the app on localhost easily enough, and all of the functionality seems to be good, but I can't figure out how to get this hosted on the public IP of the computer. We've been using yarn to do all of this, though i've tried other things, so here's some cli output.
path/to/thing# yarn start
yarn run v1.22.5
$ react-scripts start
Attempting to bind to HOST environment variable: public.facing.ip.address //This is a website name
If this was unintentional, check that you haven't mistakenly set it in your shell.
Learn more here: //There was a link here but SO formatting wouln't let me keep it.
Could not find an open port at public.facing.ip.address.
Network error message: listen EADDRNOTAVAIL: address not available public.facing.ip.address //numeric
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
root#computer:path/to/thing#
When I run hostname -I, public.facing.ip.address does not appear at all. So that seems like the obvious issue. The catch here is that we are also running jenkins on a separate port of public.facing.ip.address from this same computer. That was much easier to set up, it just came as something I could start as a service using 'systemctl start jenkins' and up it went onto the public facing IP. I set all that up and I can access it just fine, etc. The best I can do with this is modify the HOST variable either in the terminal or the .env file, then yarn starts a development server on localhost (which I can't access since I'm on a different network SSHing into this computer)
How do I make yarn host our webapp on the public facing IP?
open your router page, there should be dmz host option somewhere, point it to your local ip address
My networking inexperience was the culprit. Instead of using HOST=path.to.public.ip, the solution was to use HOST=0.0.0.0.
I am new to the node world. I created a node js rest API. When I run npm start in my local machine or in the terminal for the first time, I can see console.log() in my terminal. Now, I am running the same application on an AWS Ec2 instance with Ubuntu as os. I run npm start and serve my app on port 80. I do this via ssh and after running my server I close the ssh connection. But when I reconnect via ssh, I want to see those console.log() messages in my terminal for some purpose.
I completely understand that logging messages in the terminal is not a good idea and there can be so many alternatives. Just want to know how to access the same terminal window/result as we see when I start my application.
if you are using pm2, you can try "pm2 logs"
So Nodemon won't work well in a production server or in any instance where you need to have the app going by itself.
Nodemon is a dev tool to enable you to restart your server during development. In a "real" vps you need to place the process in the background or it will be automatically killed when the connection times out.
Check out this YT series for a correct deploy architecture in an NGINX server with the use of pm2 and NGINX on a Red Hat server, I've personally used it more than once:
https://www.youtube.com/playlist?list=PLQlWzK5tU-gDyxC1JTpyC2avvJlt3hrIh
I haven't made any changes, I just run "create-react-app client", then everything runs correctly, I cd into the directory and run "yarn start".
Then I have two problems:
1) It says "Something is already running on port 3000". Unfortunately when I use lsof and netstat, nothing is running on port 3000. I say to run on a different port, and it then attempts to serve the app.
2) Nothing is served on the new port. The browser opens up, the console gives no errors, but nothing gets served to the browser.
node version 8.7.0
yarn version 1.3.2
create-react-app version 1.3.3
OS MacOS
My hosts file was empty, so "localhost" didn't mean anything.
127.0.0.1 localhost fixed it.
I have an AngularJS application that does an ajax call but it results in a chromium error:
net::ERR_NETWORK_CHANGED
I tried to disable any adapters that I don't need. I have multiple ones and multiple dockers containers running.
I disabled ipv6 on each adapter. I don't use any proxy and use default Chromium browser without any addon nor browser profile.
Disabled Wifi interface, only using ethernet.
Any idea how to fix this?
I was constantly getting ERR_NETWORK_CHANGED.
This is what finally worked for my current browsers:
Chromium, Opera and FlashPeak Slimjet.
sudo service docker stop
The following actions did not solve my issue:
Checked modem, router, and cables to isolate the issue.
Disabled IPv6 from my wired Network
Commands:
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
After I stopped Docker, I am not getting any more console errors.
I hope this can help someone saving hours of annoying troubleshooting.
Ron.
sudo service docker stop
But this is not a solution because I need docker in my daily work.
So I found out that docker networks cause this problem
docker network prune helped me
Or try to delete one by one except of none, bridge, host
Based on the original answers, I want to go into more detail what fixed it in my case.
Stopping the docker service sudo service docker stop in my case fixed the issue.
The underlying issue one of my docker-compose setups having restart=always.
Unfortunatly I had a bug causing a container to terminate and restart. This restart caused the network change.
It is determinable by running docker ps and noticing the container restarted.
I fixed the problem and ran docker-compose down for my docker compose setup. Both actions would fix it independently.
Furthermore a Bugreport for chromium exists regarding this issue, but it has the state wontfix.
I'm now able to run a Dart app using
gcloud --verbosity debug preview app run app.yaml
and also to deploy and run on AppEngine
gcloud --verbosity debug preview app deploy app.yaml
but I haven't found a way to connect a debugger to the Dart app running on the development server.
I found http://dartbug.com/21067 but still couldn't find a way to make it work.
See also https://groups.google.com/a/dartlang.org/forum/#!topic/cloud/OK1nJtg7AjQ
Update 2015-02-27
The app can be run without Docker and then be debugged like any Dart command line application:
Source. https://groups.google.com/a/dartlang.org/d/msg/cloud/zrxgOHFz_lA/q5CdLLQPBAgJ
The API server is part of the App Engine SDK, and we are using it for
running tests in the appengine package. If you look at
https://github.com/dart-lang/appengine/blob/master/tool/run_tests.sh
you will see that it expects the environment variable
APPENGINE_API_SERVER.
The API server is in /platform/google_appengine/api_server.py
and takes a number of arguments. I just tested running it like this:
$ $CLOUD_SDK/platform/google_appengine/api_server.py \ -A
dev~test-application \ --api_port 4444 \ --high_replication \
--datastore_path /tmp/datastore
To run an app engine application outside the normal development server
requires that a number of environment variables are set. This worked
for my application:
$ GAE_LONG_APP_ID=test-application \ GAE_MODULE_NAME=default \
GAE_MODULE_VERSION=version \ GAE_PARTITION=dev \ API_PORT=4444 \
API_HOST=127.0.0.1 \ dart bin/server.dart
In the Dart Editor you cannot set environment variables for each
launch configuration, so they have to be set globally before starting
the Dart Editor. In WebStorm it is possible to have run configuration
specific environment variables.
This simple setup will of cause not support everything the normal
development server support. Some of the issues are:
Only one application at the time as it is always listening on port
8080 (can easily be made configurable) * The users API (mocking this
shouldn't be that difficult) * The modules API * No health-checks
(should not be a problem) * All HTTP headers are direct from the
client (no x-appengine- headers) * The admin web interface is not
available * Probably other stuff as well
This is all experimental, but it is one solution for a simpler
developer setup, which of cause does not match the deployment
environment as closely as the development server.
Running the API Server using Docker is also possible as the image
google/cloud-sdk with the Cloud SDK is on hub.docker.com.
Use the following Dockerfile
FROM google/cloud-sdk EXPOSE 4444 ENTRYPOINT
["/google-cloud-sdk/platform/google_appengine/api_server.py", \
"-A", "dev~test-application", \ "--api_port", "4444", \
"--high_replication", \ "--datastore_path", "/tmp/datastore"]
Build and run
$ docker build -t api_server . $ docker run -d -p 4444:4444 api_server
Change API_HOST above to 192.166.59.103 (of wherever your Docker
containers are) and run.
Regards, Søren Gjesse
Update 2014-11-27
Debugging from DartEditors debugger started working with the bleeding Dart build 1.8.0.edge_042017.
I assume that the next dev build (probably 1.9.0-dev1.0) will include the related fixes as well?
Detailed steps how this works can be found here: https://groups.google.com/a/dartlang.org/d/msg/cloud/OK1nJtg7AjQ/u-GzUDI-0VIJ
Build a custom Docker image with the latest Dart dev build 1.8.0-dev.4.6.
The Dart team is actually preparing an easy way to do this yourself (see https://github.com/dart-lang/dart_docker)
Installe the latest bleeding_edge on the host system (using this script https://gist.github.com/zoechi/d240f56a32ed5649797f or manual download from http://gsdview.appspot.com/dart-archive/channels/be/raw/latest/editor/darteditor-linux-x64.zip)
Add this to the app.yaml file
env_variables:
DBG_ENABLE: 'true'
# disable health-checking because this is so annoying during debugging
vm_health_check:
enable_health_check: False
See How to disable health checking for `gcloud preview app run` for more details about customizing health checking.
Launch the server code of your app with glcoud --verbosity debug app run app.yaml or glcoud --verbosity debug app run app.yaml index.yaml
Wait until the Docker container is ready (check with docker ps if the Command column shows a value starting with /dart_runtime/dart_
Open DartEditor
Open Menu Run > Remote Connection...
Connect to: Command-line VM
Host: localhost if you dont use boot2dockeror the IP address returned by the commandboot2docker ip`
Port: 5005
Select Folder... select the directory which contains the source code of your project.
Click OK
Set breakpoints and continue as usual.
Old
A first step is using the Observatory which includes a browser based debugger UI.
To make this work add the following lines to the app.yaml file
network:
forwarded_ports: ["8181"]
This might be useful as well to make the server.dart wait until we had the chance to set breakpoints using the observatory.
env_variables:
DART_VM_OPTIONS: '--pause-isolates-on-start'
boot2docker gives us the Docker ip (192.168.59.103) and after starting with gcloud preview app run app.yaml we can connect to http://192.168.59.103:8181 which should open the Observatory GUI.