I have a nodejs server and I'm writing some migrations.
For some reason my script is not recognizing the desired name for the migration:
this is my script:
"create-migrate": "migrate-mongo create $NAME"
This is supposed to let me use something like :
npm run create-migrate init-data
and create a migration named "init-data".
What happens - it's just creating the migration using the "$NAME" as the name...
I'm not sure if it has something to do with me working on windows or not,
anyway I will be thankful for some light here.
Actually you don't need the $NAME argument
just use like this
"create-migrate": "migrate-mongo create"
and what ever you pass after create-migrate will become it name
example
npm run create-migrate init-data
I am having an issue with creating a new file while my snap is running; example:
1) Snap starts and checks for the config.json file at ./config/config.json
2) If that file is not found (it never is the first time the application runs) it will create it fs.writeFile('./config/config.json', 'My Data', 'utf8', (err) => {....})
3) I Then look for that file later to use it.
I am able to run my node app and all works as expected when using node index.js
I am also able to run using snap try prime/ --devmode and all works.
When running snap try prime/ I get this error in the syslog
Error: ENOENT: no such file or directory, open './config/config.json'
It is erroring at the point of creation.
Any help with this would be awesome!! Thanks in advance.
I was able to solve this by NOT creating and checking for the config files in NodeJS and moving all of that logic to an install hook (https://docs.snapcraft.io/build-snaps/hooks).
So now my Install hook will check for the config file and create it if it's not there, then I allow NodeJS to write to that file later so I can still make all the HTTP requests in NodeJS and not in Bash. Below is my Install hook, don't forget to make it executable.
This file is located at snap/hooks/install
#!/bin/sh
set -e
CONFIG_FILE=$SNAP_COMMON/config.json
if [ ! -f $CONFIG_FILE ]; then
# File Not Found, Create it
echo '{}' > $CONFIG_FILE
fi
Hope this helps someone!
I have a node application that I run on a Linux Server (CentOS 6.5) by setting my environment with a bash script
env_nodejs.sh
#!/bin/bash
PATH=$PATH:/opt/nodejs/node-v6.9.4-linux-x64/bin
export PATH
So that I can
# . ./env_nodejs.sh
# node /var/www/html/application/app.js
That all works fine but if I do the following in a separate script
run_app.sh
#!/bin/bash
$COMMAND=/opt/nodejs/node-v6.9.4-linux-x64/bin/node
$SITE=/var/www/html/application/app.js
nohup $COMMAND $SITE > /tmp/nodeapp.log &
This runs the node server and app but with errors that seem to be related to npm
Error: Failed to lookup view "control/users" in views directory "/views"
I have a feeling this is because the environment is not set but is there a way to run it correctly without the environment or to pass additional parameters for the npm location?
It seems like it's trying to find the files in "/views" which is a top level directory in your file system.
If that is the case then it's not PATH but PWD that's in fault here.
Make sure that when you define where to look for the views in your app, instead of saying 'views' or './views' you use path.join(__dirname, 'views') instead.
You first need to require path with: var path = require(path);
Of course this is just my guess as you didn't include any part of your source code that you have problem with.
I'm currently starting up my NodeJS application and I have the following if-statement:
Error: ENOENT, no such file or directory './realworks/objects/'
at Object.fs.mkdirSync (fs.js:654:18)
at Object.module.exports.StartScript (/home/nodeusr/huizenier.nl/realworks.js:294:7)
The weird thing, however, is that the folder exists already, but the check fails on the following snippet:
if(fs.existsSync(objectPath)) {
var existingObjects = fs.readdirSync(objectPath);
existingObjects.forEach(function (objectFile) {
var object = JSON.parse(fs.readFileSync(objectPath+objectFile));
actualObjects[object.ObjectCode] = object;
});
}else{
fs.mkdirSync(objectPath); // << this is line 294
}
I fail to understand how a no such file or directory can occur on CREATING a directory.
When any folder along the given path is missing, mkdir will throw an ENOENT.
There are 2 possible solutions (without using 3rd party packages):
Recursively call fs.mkdir for every non-existent directory along the path.
Use the recursive option, introduced in v10.12:
fs.mkdir('./path/to/dir', {recursive: true}, err => {})
Solve here How to create full path with node's fs.mkdirSync?
NodeJS version 10.12.0 has added a native support for both mkdir and mkdirSync to create a directory recursively with recursive: true option as the following:
fs.mkdirSync(targetDir, { recursive: true });
And if you prefer fs Promises API, you can write
fs.promises.mkdir(targetDir, { recursive: true });
When you are using fs.mkdir or fs.mkdirSync, while passing the path like folder1/folder2/folder3, folder1 and folder2 must exist otherwise you will get the above error.
The following worked for me:
fs.mkdir( __dirname + '/realworks/', err => {})
Problem was caused by forever running the application relative to the working directory the forever start command is called in, not the location of the application entrypoint.
Try:
fs.mkdir('./realworks/', err => {})
The reason for the error is that if any of the folders exist along the path given to fs.mkdir or fs.mkdirSync these methods will throw/callback with an ENOENT error.
ENOENT is described in the linux documentation as the following:
No such file or directory (POSIX.1-2001).
Typically, this error results when a specified path‐
name does not exist, or one of the components in the
directory prefix of a pathname does not exist, or the
specified pathname is a dangling symbolic link.
Another possible reason for ENOENT is that you lack sufficient privileges to create the directory.
This happened to me while building a docker image where I didn't have sufficient privilege to create a subfolder in the current WORKDIR. Changing the owner of the folder using --chown=user:usergroup OR changing the USER to the root user for the directive were both valid solutions to the problem.
WHAT WORKED FOR ME WAS ;
Deleting my yarn.lock, package-lock.json, and nodemodules
reinstalling with yarn build
restarting my local server
so... you probably might be using ubuntu terminal to create your react app.
It happens to me that I am testing the ubuntu terminal that windows recently launched to be installed on windows computer, like a virtual machine but actually not so messy.
I occured to have the same error as you folk, after testing all the options that the community has given before, none of them work. However, i did find a solution for my problem. It was giving me the ENOENT error, like, test file or directory not found. but I was there indeed. I was using npm start, and came up with the idea of using sudo npm start... and it worked.
I have a gulp.js process using the gulp-phantom plugin that works perfectly on my dev setup, Mac OS X 10.10, however on my test / prod environment (EC2 Amazon Linux) it just doesn't work at all, however it also isn't giving any sort of error message or any other helpful output, the task just starts and finishes again almost straight away:
Dev environment output:
$ gulp crawlSite
[17:39:19] Using gulpfile ~/Documents/dev/mysite.co.uk/gulpfile.js
[17:39:19] Starting 'crawlSite'...
[17:40:15] Finished 'crawlSite' after 57 s
Test environment output:
$ gulp crawlSite
[17:34:27] Using gulpfile /var/www/html/mysite.co.uk/gulpfile.js
[17:34:27] Starting 'crawlSite'...
[17:34:27] Finished 'crawlSite' after 715 ms
As you can see on the dev environment the process takes 57 seconds however on test it is only 715 milliseconds and on test it is not creating the files that my phantom script should be creating. My gulp task is very simple:
gulp.task('crawlSite', function() {
return gulp.src("phantom-crawl-website.js")
.pipe(phantom());
});
and my phantom script "phantom-crawl-website.js" file is in the same directory as the gulpfile.js file.
I have check that all the node modules are installed and that PhantomJS is installed globally on the test environment and everything checks out ok. If I run:
$ phantomjs phantom-crawl-website.js
from the command prompt on the test environment that works fine and it crawls the site and creates the files.
I have tried to use the gulp-phantom options for "debug" however I can never seem to see any output from this. I have tried using gulp-debug as well as follows:
gulp.task('crawlSite', function() {
return gulp.src("phantom-crawl-website.js")
.pipe(phantom({debug: true}))
.pipe(debug());
});
However all this does is give me the gulp-phantom output filename ("phantom-crawl-website.txt"). I have also tried to write the gulp-phantom output file in the following way:
gulp.task('crawlSite', function() {
return gulp.src("phantom-crawl-website.js")
.pipe(phantom({debug:true}))
.pipe(gulp.dest("./phantomOutput/"));
});
But all I get from this is a blank file created in the "phantomOutput" directory called "phantom-crawl-website.txt".
Can anyone advise what I am doing wrong and how I would be able to see the phantomJS debug output so I can work out what the problem is.
Thanks so much in advance.
UPDATE
I've managed to get some output from the gulp-phantom process by adding the following to the gulp-phantom index.js file:
program.stderr.on('data', function (data) {
console.log('stderr: ' + data);
});
Once this was added I'm now getting the following error message:
stderr: Can't open '/dev/stdin'
But still no luck actually getting it to work.
Found the issue. In the gulp-phantom module there appears to be an error with it using /dev/stdin were phantomjs expecting the phantom filename to be passed. On Mac OS X the /dev/stdin contains the contents of the file but on Linux it is denied permission to read it.
To fix it I removed the line that was pushing '/dev/stdin' into the arguments stack and then added one a bit further down in the "through" function call to pass the full path and filename to the phantomjs process instead.
I will issue a pull request to the gulp-phantom module creator and see if they accept this as fix for the issue.