I am using VSCode for Reactjs and in the starting when i was learning reactjs, there was no need to restart the server but now after every modification, I have to restart the server and then only the changes are applied on the server
you were probably using nodemon or pm2 or similar tool to watch for file content during development.
on production, that feature is probably not used.
to verify this, looks for scripts section in the package.json file and see what command did you use to develop locally and run on production
Related
I want to learn React. so I installed Nodejs(v 10.16.0 LTS) and then using Windows Powershell I run following commands
npx create-react-app my-app
cd my-app
npm start
After installing, When I try to make a change in any code (like changing page title name), after saving code file. The Tab in Browser does not reload automatically and when I reload tab manually the error occurs which say
This site can’t be reached
localhost refused to connect.
Try:
Checking the connection
Checking the proxy and the firewall.
If I start this using PowerShell using npm start* command, then it run successfully. but I have to do this every time even when I edit my code. Browser tab did not reload and apply changes automatically.
Kindly guide me about this issue. Thanks
you need to add react-hot-loader in your project react doesn't come with hot reload you need to include it in your project below is the link to npm please go through the documentation they provide once, and add it in your project.
You shouldn't need react-hot-loader or anything else if you've created your react app through create-react-app - just make sure you're using the latest stable version of create-react-app
In your react app, when you run npm start, it uses react-scripts start script which behind the scenes uses webpack which actually takes care of hot module replacement
The problem you're facing seems most likely related to your local setup. Can you try running your app on a different port 8080 maybe?
Secondly, hot module replacement uses a websocket connection, can you check in your console if there is any error related to ws connection?
I am try to search this question by google.But not helpful for me.
I hava a demo of create-react-app.
Run it in localhost(npm start), that work well when browser disable cache.for example:
localhost
The step was run npm run build in localhost.then scp -r build server:/home/deploy/app/.run it by nginx.
Then open the browser to run,that initialization or refresh slowly when disable cache too. for example:
server
you could find load 500KB js file need 15seconds in server.
I guess that is a relationship with bandwidth. My server bandwidth was 1M/s.but i'm not sure.
ps: I'm sorry I forgot to declare the specific environment, but I did these steps.
If you're running this in production, I wouldn't suggest you running the web-application with npm start on the server.
A much better solution would be to run npm run-script build by which you'd get a response as such:
Creating an optimized production build...
Compiled successfully.
File sizes after gzip:
48.12 KB build/static/js/main.9fdf0e48.js
288 B build/static/css/main.cacbacc7.css
The project was built assuming it is hosted at the server root.
To override this, specify the homepage in your package.json.
For example, add this to build it for GitHub Pages:
"homepage" : "http://myname.github.io/myapp",
The build folder is ready to be deployed.
You may serve it with a static server:
sudo npm install -g serve
serve -s build
You could either do serve -s build or set up nginx or apache to serve the files (it's just html, css and js). You could also use Github Pages to host it.
Are you missing the build step?
If yes, try npm run build or yarn build. It will output an optimized version of your app to ./build directory. You can then host it on your server with nginx or other server setup.
More info here: official docs
When you do npm start npm starts the development version of your app.
It includes some debug code, error checking and live refresh.
I'm learning to use webpack-encore and noticed it is installed only as a dev dependency. Does that mean I should compile my js and css files on development and push them to the repository, and then to production?
That seems to me what the docs are implying, but wouldn't that mean a merge-conflict hell? Compiled files would be impossible to merge.
Also wouldn't that be contrary to version control philosophy? As far as I know, you don't publish binaries in compiled languages (i.e. C/C++), you push the code and expect the server to compile them. I know this isn't the same type of "compilation" in javascript, but what is the expected behavior of the production server in this case? To receive the files ready to serve them, or to compile them at the time of release?
Thanks in advance
Does that mean I should compile my js and css files on development and push them to the repository, and then to production?
Not exactly - it depends on how you deploy.
When you deploy, you need to run ./node_modules/.bin/encore production to build your assets. Once you've done this, only your built assets (e.g. web/build) need to be transferred to production.
You could run this command locally (or on some "build" server) and the transfer all the files to production. Or, you could use a git pull on production, and then run this command on production (the downside being that you would need Node.js installed on production).
You shouldn't / don't need to commit your built files to your repository. But... if it simplifies your deploy (i.e. you want to do a git pull and be done), there's no real problem with that.
I just added a PR to answer these in the FAQ (http://symfony.com/doc/current/frontend/encore/faq.html) - here's the PR until it's deployed: https://github.com/symfony/symfony-docs/pull/8109
Cheers!
Solution 1:
Run yarn run encore production locally
Check out which files have been created / modified
Add them to VCS
Commit
Push / deploy
Solution 2:
Push / deploy
Run yarn run encore production remotely during deployment
To my eyes the 2nd solution is way better, because you don't need an extra human-checking before deployment, everything is automated.
But this has a strong drawback: building assets can be a slow process, and when I deploy, my production is down during 5 to 20 seconds until assets are built.
Here's the HTTP 500 error:
An exception has been thrown during the rendering of a template ("Asset manifest file "[...]/web/build/manifest.json" does not exist.").
It looks like the manifest.json file is deleted at the beginning of the process, and created from scratch later on.
Something that should be improved?
I am currently trying to generate native versions of a small meteor app I built. When I run them on iOS or Android via the meteor run command it works and meteor build with --debug also generates an ipa/apk that works as expected. But when I run meteor build without --debug the web view only shows a white screen. Using remote debugging I noticed an injector error. I was wondering why and checked the apk/ipa content. There I recognized that in the debug version under assets/www/application/packages there is a bunch of .js and .js.map files which simply is not there in the non-debug ipa/apk.
In the index.html of the non-debug ipa/apk the imports of these files are also missing.
How can I tell meteor to just copy these obviously required files for non-debug?
When you build, Meteor concatenates and minifies all the JS files into a single bundle, same as Browserify and webpack are doing. That is why you do not see all the script imports.
It does not do it in debug to facilitate live reload / hot code push while you are developing, besides facilitating debugging​ obviously.
See the Meteor guide on building for production.
If you believe this difference causes some issue, you can simulate it in development using the --production flag after meteor run.
This addresses your titled and last question, but may not fix in itself your initial issue.
I'm working on node.js app that is written in Typescript, which means it needs to be compiled to JS before running. As I'm coming from java/jvm background where you ship prebuilt package to server and it gets run there I'm a bit afraid of the way of deployment where you push code to git and it's being built/compiled on server first and then run.
I don't like it for two main reasons:
dev dependencies need to be installed on server
deployment depends on external resources availability (npm etc).
I found NAR https://github.com/h2non/nar which is more or less what I wanted but it has some drawbacks (doesn't work with some deps that have native extensions).
My question is: is there any other "sane" way of doing deployment node.js deployment than this risky combination of npm install and tsc on server? Or should I let that sink in and do it that way?
To be honest I don't believe there are no more sane/reliable options for that.
What you can do (but there are probably other perfectly valid approaches) is building your project locally (or on a CI service), and only deploy this built version when you consider it as valid (tests, etc.).
This way, if something bad happens, like npm that fails, or a compilation error, you don't deploy anything, and you have time to resolve the situation.
For example, I used to have a gulp task (but it can be anything else: Grunt, a simple npm script...) that clone a production repository and build the project into this directory.
That way, I can check that my build is valid. If it is, I make a new commit and push it to the production repo, that is served the way you need (on a Heroku instance for example).
Pros
Clear separation of dev and non-dev dependencies
Deployment only when you know that the build is valid
No built files on source control on the development repository
No "live" dependency on external tasks like npm install or tsc build
Cons
You have two separated git repositories (one with the source code, one with the built version of your project)
Production process is a little bit heavier than simply committing to master
(From comment) Doesn't properly handle the case of npm package that relies on native extensions that have to be (re)built
is there any other "sane" way of doing deployment node.js deployment than this risky combination of npm install and tsc on server
package.json + npm install + tsc is the way to do it. Nothing risky about it.
More
Just use an npm script : https://github.com/TypeStrong/ntypescript#npm-scripts