I am learning JavaScript development and the book I'm following (JavaScript Everywhere) tells me run this code:
const express = require('express');
const app = express();
app.get('/', (req, res) => res.send('Hello World'));
app.listen(4000, () => console.log('Listening on port 4000!'));
I understand what this code is supposed to do but when I try to run it using src/index.js in the terminal, it always gives me this error:
Syntax Error 800A03EA Microsoft JScript compilation error
I have tried all fixes I found on the internet but I'm guessing this has something to do with the fact that this isn't regular JS syntax, it's Express JS and somehow Express JS is not enabled? I've checked the basics including:
node --version (returns v12.14.0)
npm --version (returns 6.13.4)
npm install express --save just in case there was some problem with ExpressJS API
Windows 10 Laptop, using VSCode. Please ask for any information you need.
Run it using node src/index.js.
By using just src/index.js you are using the default handler for JS files on Windows which is Windows Script Host (and not Node.js).
The solution apply for those who are facing Windows script Error code like 800A03EA. For those, who are unable to open js file and facing error like Windows Script Host.
I was stuck with the same problem for couple of days while working on react.
We have three methods of solving this problem:
Method 1:
Check your computer for viruses and remove them using various method like download MSERT.exe from Microsoft.
Method 2:
Open command prompt as administrator and type following 2 commands:
regsvr32 jscript.dll and press ENTER.
regsvr32 vbscript.dll and press ENTER.
Method 3:
Type internet option on search bar and select it.
Open advance gtab from it and go to security section.
Make sure all of the below ones are selected:
Use SSL 3.0
Use TLS 1.0
Use TLS 1.1
Use TLS 1.2
Method 4:
The workaround that must work 100% but as you know it might be helpful for all, as it only open file do not confuse read the following lines
So simply left click on file and edit and open it.
It will open in notepad and now from here you can transfer your data or use it.😁
Thanks me later for this detail answer. Now just rock the world!!!!!
Check if your file name isn't "Node.js", just try to rename it in like "randomname.js"
When I start my server with node app.js in the command line (using Git Bash), I can stop it using ctrl + C.
In my package.json file i got this start-script that allows me to use the command npm start to start the server:
"scripts": {
"start": "node app"
},
When I do this, the server starts as normal:
$ npm start
> nodekb#1.0.0 start C:\Projects\nodekb
> node app.js
Server started on port 3000...
But when i ctrl + C now, the server does not get stopped (the node process still remains in task manager). This means that I get an error when I try to do npm start again, because port 3000 is still being used.
I'm following a tutorial on youtube (video with timestamp), and when this guy ctrl + C and then runs npm start again, it works as normal.
Any ideas why my server process is not stopped when I use ctrl + C?
My app.js file if needed:
var express = require("express");
var path = require("path");
//Init app
var app = express();
//Load View Engine
app.set("views", path.join(__dirname, "views"));
app.set("view engine", "pug");
//Home Route
app.get("/", function(req, res) {
res.render("index", {
title: "Hello"
});
});
//Add route
app.get("/articles/add", function (req, res) {
res.render("add_article", {
title: "Add Article"
});
});
//Start server
app.listen(3000, function() {
console.log("Server started on port 3000...");
});
Thanks!
Ctrl + C does not kill the server. The resolution to the issue was using following code snippet in server.js:
process.on('SIGINT', function() {
console.log( "\nGracefully shutting down from SIGINT (Ctrl-C)" );
// some other closing procedures go here
process.exit(0);
});
This worked for me.
You can also check for other solutions mentioned at Graceful shutdown in NodeJS
I tried it on normal windows cmd, and it worked as it should there. Looks like it's a problem with git bash.
I encountered this problem in MSYS2 proper, even in latest build (x64 2018-05-31).
Luckily, Git for Windows maintain a customized MSYS2 runtime. They have patches that have not been sent upstream, including a patch that fixes emulation of SIGINT, SIGTERM and SIGKILL.
Discussion: https://github.com/nodejs/node/issues/16103
I was able to make my "MSYS2 proper" platform use Git for Windows' MSYS2 runtime, by following these instructions.
Repeated here for posterity:
Install inside MSYS2 proper
This guide assumes that you want the 64-bit version of Git for Windows.
Git for Windows being based on MSYS2, it's possible to install the git package into an existing MSYS2 installation. That means that if you are already using MSYS2 on your computer, you can use Git for Windows without running the full installer or using the portable version.
Note however that there are some caveats for going this way. Git for Windows created some patches for msys2-runtime that have not been sent upstream. (This had been planned, but it was determined in issue #284 that it would probably not be happening.) This means that you have to install Git for Windows customized msys2-runtime to have a fully working git inside MSYS2.
Here the steps to take:
Open an MSYS2 terminal.
Edit /etc/pacman.conf and just before [mingw32] (line #71 on my machine), add the git-for-windows packages repository:
[git-for-windows]
Server = https://wingit.blob.core.windows.net/x86-64
and optionally also the MINGW-only repository for the opposite architecture (i.e. MINGW32 for 64-bit SDK):
[git-for-windows-mingw32]
Server = https://wingit.blob.core.windows.net/i686
Authorize signing key (this step may have to be repeated occasionally until https://github.com/msys2/msys2/issues/62 is fixed)
curl -L https://raw.githubusercontent.com/git-for-windows/build-extra/master/git-for-windows-keyring/git-for-windows.gpg |
pacman-key --add - &&
pacman-key --lsign-key 1A9F3986
Then synchronize new repository
pacboy update
This updates msys2-runtime and therefore will ask you to close the window (not just exit the pacman process). Don't panic, simply close all currently open MSYS2 shells and MSYS2 programs. Once all are closed, start a new terminal again.
Then synchronize again (updating the non-core part of the packages):
pacboy update
And finally install the Git/cURL packages:
pacboy sync git:x git-doc-html:x git-doc-man:x git-extra: curl:x
Finally, check that everything went well by doing git --version in a MINGW64 shell and it should output something like git version 2.14.1.windows.1 (or newer).
Note: I found that the git-extra package installed by step 7 was quite intrusive (it adds a message "Welcome to the Git for Windows SDK!" to every terminal you open), so I removed it with pacman -R git-extra.
Note 2: I also found that Git for Windows' MSYS2 runtime opens in a different home directory than did MSYS2 proper's. This also means it reads in the wrong bash profile. I fixed this by adding an environment variable to Windows in the Control Panel: HOME=/C/msys64/home/myusername
I use git bash on my Windows machine and have run into this issue in the last month or so.
I still do not know what's causing it but I've found another way to stop it.
Open Task Manager
Go into the Processes tab
Look for node.exe and then press End Process
This has allowed me to stop the server quickly.
I had the same problem working with npm. But finally, I knew it was a problem with git itself.
There was a comment by dscho on GitHub 15 days ago. He said that they're working to fix this problem in the next release. He also shared the exact msys-2.0.dll file that can fix the problem for the people who can't wait.
Personally, I couldn't wait :p. So, I gave it a try, downloaded the file, and throw it in the git folder as he said. And the problem gone! It was awesome!
But please be sure to take a backup before you replace the file.
I also tried to kill it after running express as I used to; using taskkill /im node.exe on the cmd but there was no process to be found.
Check out this issue on GitHub,and search for the name of the file msys-2.0.dll to get to the comment faster.
Sometimes the node process hangs.
Check for the process ID using ps You may want to grep for node and then kill the process using kill -9 [PID]
Use Ctrl+\ to send the SIGQUIT signal. It will close the server.
Reference - https://en.wikipedia.org/wiki/Signal_(IPC)
I was able to fix this by switching to nodemon to run the server.
npm install --save-dev nodemon
package.json:
"scripts": {
"start": "nodemon app"
},
I was trying to get json-server to quit a custom server script, but it always left a child process running on Windows. It seems to be a specific problem running express via npm on Windows. If you run the server directly via the c:>node server.js then it seems to quit correctly.
I was able to debug this issue by checking the ports using TCP View, and realizing that my Node server was running even though I had pressed ctrl-C to stop it. I suggest killing the terminal you are running node from entirely.
Use Ctrl + C, then input: >pm2 stop all
This will stop all server or when you get stack with nodejs.
Inside package.json under scripts I had this line react-scripts start&. Notice it ends with an & which would send the process to the background and ctrl+c will not work. Somehow trying to bring this to the foreground with fg also did not work. Solved the problem by removing the &.
if you use Node.js Exec Extention to run your project from f8,
you can use also f9 to cancel running..
This is more than likely just a problem with your console not accurately sending the command to the process. This is pretty common, especially when using third party consoles like cmdr / conemu.
The solution?
Just hit ctrl+c several times until it closes :P
On my server, every time a user uses our service we have to grab a JSON file for them from the server. I do this by using fs.createReadStream() inside of my own function.
function getJSONFromServer(filepath, callback){
var data = fs.createReadStream(filepath);
data.on('error', function (error) {
console.log("Caught", error);
callback(undefined, error);
});
var jsonFile = "";
data.on('data', function(chunk) {
jsonFile += chunk;
});
data.on('end', function() {
var jsonData = JSON.parse(jsonFile);
callback(jsonData);
data.destroy();
data.close();
});
}
This does the job, but it does not close the connection to the file. So after reading 1024 files (the limit on my server), Node.js will then produce the error EMFILE, too many open files. Then I have to kill our Node.js server, open it again and that will clear the "open files".
I check the amount of files open by lsof -i -n -P | grep nodejs. It displays something like this:
nodejs 13707 node 10u IPv4 1163695 0t0 TCP 127.0.0.1:55643->127.0.0.1:27017 (ESTABLISHED)
nodejs 13707 node 11u IPv4 1163697 0t0 TCP 127.0.0.1:55644->127.0.0.1:27017 (ESTABLISHED)
for as many files that are open.
I've tried using graceful-fs. I've tried calling stream.destroy() and stream.close(), but I still get the same issue. My server is essentially a ticking time bomb because we get a heavy, steady flow of users and after so many users have connected it will just stop working.
Also, ulimit -n [open file amount] does not work, and even if it did, this is not a long term solution because I'd like my file connections to close and not sit open for no reason.
I'm using Node.js version v0.10.25, Ubuntu 15.04 (GNU/Linux 3.19.0-42-generic x86_64) and the latest version of graceful-fs if that helps!
Thanks for any help you can provide.
This has got to be the stupidest mistake I've ever made. Regardless, here's the answer. I hope I can save someone from dealing with this error and almost ripping their hair out.
I was running my app with nodejs and not node. Turns out, if you do nodejs --version, it will likely return a version that is very old, which was v0.10.25 for me. node --version however was v5.6.0. Obviously this massive jump in versions would fix some stuff, so I ran the app with node app.js instead of nodejs app.js and I haven't had the issue at all since. There are now only 6 open files, whereas before we had over 1000 with time.
Damn it feels good to have this off my chest.
I have node.js installed on Vagrant and WebStorm access to a project on shared folder via VirtualBox.
Can I run node.js application on WebStorm and see the output on WebStorm (Terminal or SSH)? At the moment I have to keep switching to Putty to run it to see the output, its gets quite tiring.
Running Node.js applications remotely is not currently supported, please follow WEB-6136 for updates.
Debugging remote applications is possible (using Node.js Remote Debug run configuration - see https://confluence.jetbrains.com/display/WI/Running+and+debugging+Node.js+application#RunninganddebuggingNode.jsapplication-DebuggingNode.jsappthatrunsremotely). But you can't see the remote process output in WebStorm console, as Stdout of it is not accessible via debug protocol WebStorm uses for remote debugging. Related feature request: WEB-17013
This feature is available through ssh on Webstorm 2017.1
Scroll down to Configuring a remote Node.js interpreter on a host accessible through SSH connection in the link below:
https://www.jetbrains.com/help/webstorm/configuring-node-js-interpreters.html
Is there any way to make node.js be host process for a node-webkit application?
I'm using Intellij IDEA for node.js development, and it have best debugger for node atm. But node-webkit presents its own nw.exe process, which can't be debugged by normal node.js environment. Other debug options (chrome devtools) don't match in effeciency with IDEA debug.
IDEA present some kind of nw debug support, but its very raw and works with many glitches and not works for many things.
So I want develop node-webkit app which starts under control of node.js process, like appjs was doing.
You could do that if you manage to launch nw.exe in debug mode using child_process.exec and make sure the line "Debugger listening on port [nnnnn]" is written to stderr, because according to https://youtrack.jetbrains.com/issue/WEB-1919#comment=27-556387
IDE parses it and can understand that a new debug session should be initialized and what debug port is.
That would be enough BUT the problem is:
child_process.exec will not return stderr until the child process ends and it does not provide a way to pipe it to the node.js host.
node-webkit only provide a --remote-debugging-port option to specify the port to open a devtools debugger; there's no option to start in debug mode (something like --debug or --debug-brk)