I created a command-line app that uses a .env file in conjunction with the dotenv NPM module to handle API credentials. So invoking the entry point like node main.js in the project dir works.
I'm now building a web-interface and invoking this application using the child_process module. The problem is that the environment variables are now mismatched. The command-line app sees process.env.APIKey as undefined and it crashes.
Now I think this is a unix-specific issue. How can I solve this problem (specifically, invoking main.js programmatically while retaining its own environment variables scope).
Related
I'm trying to access items in my PATH environment variable from my electron instance, when I run it with npm start while developing it through node.js I get all the expected variables, but when I run the electron application with my resources inside I'm left with only usr/bin
This is how it looks like when I run it from npm:
And this is how it looks when run from the electron mac application precompiled:
Does anyone know why this could be the case? And if I can do anything to reach my normal PATH variables
UPDATE:
After a lot of research I found out that GUI applications ran from finder or docker in Mac OSX use different environment variables compared to if they are ran from the terminal:
This can be edited through plist files, either globally or application specific
You can use fix-path package. Works perfectly!
const fixPath = require('fix-path');
console.log(process.env.PATH);
//=> '/usr/bin'
fixPath();
console.log(process.env.PATH);
//=> '/usr/local/bin:/usr/bin...'
I have used dotenv module to load environment modules into a config file. When I execute that file using node config.js I know that it has been loaded successfully(used console.log and saw output on the terminal). But when I am trying to run the entire project, it comes out as undefined in the console of the browser. Can anyone have a particular reason as to why this is happening?
running node config.js would run the file for sure and env variable will be available only during the life of this script. that's the reason you are not getting env variable in other places. try to inject require('dotenv').config() in the right place where you are consuming them. e.g build script. hope it helps.
so i usually use ruby irb, and I can pull .rb files I wrote into the console environment by running
load './script.rb'
and then all of the functions I wrote in script.rb will be available.
I cannot figure out for the life of me how to do this in the node "console" environment!
You can load JavaScript files using the require function. The following example assume that the Node.js process was started at the directory where your file is located.
require('./script.js');
This will execute the contents of the file.
If you have exported functions or objects, you can assign them to a variable and use them later.
const myFunction = require('./script.js').myFunction;
myFunction();
Like many other development frameworks/languages, Node has a Modules/Package System which, is a CommonJS variant. To load a Module use require(). The usage of require() is the same when running JavaScript files or running in the REPL.
You can require Node Core Modules, NPM Installed Packages or your own local modules. When loading NPM Packages specified in a package.json or a local module, Node will load them from the Current Working Directory(CWD), you can check this using process.cwd(). The CWD will be set to the absolute path of the directory you launched the REPL from.
You can launch the REPL via running node in your CLI and require your packages like below.
// Core Package
const os = require('os')`
console.log(os)
// NPM Package
const moment = require('moment')
console.log(moment)
// Local Package
const myPackage = require('./myPackage')
console.log(myPackage)
You can also pre-require module(s) using the -r flag when running node. The below will launch the Node REPL with the os package preloaded. You can then access the os package using the variable os
node -r os
console.log(os)
In the future, Node may also support ECMAScript Modules (ie. import). You can read more detailed info about that in the Enhancement Proposal.
I've written a Casperjs script to do some scraping, however, after running into memory exhaustion issues, I've now written a node script to turn Phantom off and on via exec. I can run this with no issues locally, however when I deploy to heroku I get the following error
Error: Command failed: casperjs turnitoffandon.js
ERROR: stderr was:/bin/sh 1: casperjs: not found
I used the nodejs buildpack and have Phantom and Casper defined in my dependencies. In the heroku bash, running phantomjs --version returns 2.1.1 and casperjs --version returns 1.1.4.
Do I need to define where Casper is? If so how? I have set my PATH variable as /usr/local/bin:/usr/bin:/bin:/app/vendor/phantomjs/bin:/app/vendor/casperjs/bin:/node_module/casperjs/bin , like in this SO question
The issue actually had nothing to do with Heroku. As noted in this SO answer, using exec and providing any environmental variables in the options parameter replaces the entire set of environment variables. This includes the path, effectively overwriting any paths already specified to Heroku in the buildpack and npm modules.
You can create a copy of process.env and pass that along in the parameters in addition to other environmental parameters needed to be passed.
Having started to work on node.js recently, I am trying to use rename package. Successfully installed (npm install rename) package and sample code (residing in file test.js) is pasted below:
console.log('Starting to rename');
var rename = require('rename');
rename('a.js', 'b.js');
console.log('Rename done');
The file a.js resides in the same directory as test.js. The console shows the two debug messages correctly, but the file a.js is not renamed.
How can I enable debug on rename module (or for that matter any node module), so that I can debug it additional log messages?
Note: Other packages like find, mkdirp, etc are working fine.
You can enable debug by doing a DEBUG=* node app.js or passign env variable DEBUG with wildcard * . It would enable debug for all modules, provided the module you wish to debug is actually using debug.
Hardcore way of doing is to make local changes in the module.