I'm trying to use an environment variable in my serverMiddleware in Nuxt.js. It works fine when it starts with a letter (MY_SECRET) but since it's a private server variable I'd like it to start with an underscore (_MY_SECRET). However for some reason the latter is undefined.
This is my basic setup:
// .env
MY_SECRET = hello
_MY_SECRET = world
// serverMiddleware/index.js
console.log(process.env.MY_SECRET, process.env._MY_SECRET) // output: hello undefined
Why does this happen and what other options do I have to prefix my private variables?
Nvm, you cannot use runtimeConfig in a serverMiddleware (probably because it is out of the Nuxt context) as shown here: https://github.com/nuxt/nuxt.js/issues/2033#issuecomment-773181809
I tried it myself with an underscore and it's working great with a publicRuntimeConfig.
After some research aka this answer and reading the official spec, on top of some Wikipedia, it looks like _ is a valid character for an env. Meanwhile, it is also used as a separator.
I've tried several things, found out that if you prefix it with a _, you won't even have it in process.env, this is not a dotenv issue neither (checked this one too), so I just guess that this is not possible.
Solution
Use PRIVATE_MY_SECRET and you should be good!
Related
Can anyone please tell me why require function sometimes use ":" when importing modules in nodejs.
Example:
var debug = require('debug')('express:router');
This looks to be a particular feature of the debug module in which what comes to the right of the colon is used to indicate what's being debugged to make it easier when others are debugging - a precise, unique name helps. As the documentation says:
If you're using this in one or more of your libraries, you should use the name of your library so that developers may toggle debugging as desired without guessing names. If you have more than one debuggers you should prefix them with your library name and use ":" to separate features. For example "bodyParser" from Connect would then be "connect:bodyParser". If you append a "*" to the end of your name, it will always be enabled regardless of the setting of the DEBUG environment variable. You can then use it for normal output as well as debug output.
Your code same:
var Debug = require('debug');
var myLog = Debug('express:router');
Just require and call module without use a temporary variable to save module
I am using the Config crate in Rust, and would like to use environment variables to set keys inside a section of the config. The end goal is to override application settings from a docker compose file, or docker command line, using the environment.
If my config was the following, could I use a specifically crafted environment variable to set database.echo ?
(code blurb below is taken from this example)
debug = true
[database]
echo = true
The example code to configure this using the environment variables illustrates only to set keys at the top level. Wondering how to extend this. The .set() takes a hierarchical key, so I'm hopeful that there's a way to encode the path in the env variable name.
Answering my own question.
I just noticed that the Environment code accepts a custom separator which will get replaced with . (dot).
So one can set the separator to something like _XX_ and that would get mapped to a ".". Setting DATABASE_XX_ECHO=true, for instance would then change the database.echo key.
I need to use a variable between node modules folder and src folder.Is there a way to use a variable to be used within the whole project?
Thanks.
Typically this is done with process environment variables. Any project can look for a common environment variable and handle that case accordingly, as well as the node modules of said project. As long as they agree on the name, they all share the same environment. Have a good default, don't force people to set this environment variable.
The environment can be set using an environment file (do not check this into source control!), on your container or cloud configuration, or even right on the command line itself.
TLOG=info npm test
That is an example that I use frequently. My project runs logging for the test cases only at alert level - there are a lot of tests so it makes the output less verbose. However, sometimes while developing I want to see all the logs, so my project is looking for an environment variable TLOG (short for "test logging") and I can set it just for that run! Also no code change is needed, which is nicer than JavaScript variables that need to be set back to original values, forget to be turned off, etc.
Default Env Variable as per the docs:
NODE_PATH:/opt/nodejs/node8/node_modules/:/opt/nodejs/node_modules:$LAMBDA_RUNTIME_DIR/node_modules
I want to append my custom directory to it (NOT to override all)
NODE_PATH:$NODE_PATH:/opt/nodejs/mycustom-directory
I tried the above from lambda console it overrides all. $NODE_PATH is added as a string. It is not parsing $NODE_PATH
Output I got when printing env:
NODE_PATH=$NODE_PATH:/opt/nodejs/mycustom-directory
Similar Question but no Solution still: AWS lambda add PATH variable?
I needed this too, as I am using AWS Lambda Layers, which are placed on the default NODE_PATH, and wanted to also be able to use local roots to avoid long relative paths (such as import bar from foo/bar instead of import bar from ../../../../foo/bar, but I didn't find any way to append to NODE_PATH without losing the default ones - as soon as it's set, the paths to node_modules - including the aws-sdk module, are lost.
The only solutions I can think of are:
Explicitly set NODE_PATH to the default value plus your custom one (which adds an ugly dependency to lambda internal environment configuration which you shouldn't have to care about)
Put your custom library in a layer. Many times this is a good solution if you can extract sub-modules as separate layers (but it doesn't help for situations like elimination of long relative paths within the application itself like I described above).
Append programatically, by having the very first lines of your application do
process.env.NODE_PATH = process.env.NODE_PATH + ":my-custom-path";
require("module").Module._initPaths(); // This re-initalizes the module loader to use the new NODE_PATH.
require('some-custom-module-in-my-custom-path'); // should work
require('aws-sdk') // should also work
This may not be the prettiest hack, but it should do the trick (disclaimer: haven't actually tried this in a AWS Lambda environment but it works locally using Node 12 at least).
I came up with the same problem.
I wrote a code to check if the lambda function applies the shell variable expansions, and to figure out they don't.
I set environment variable FOO as $NODE_PATH,
Then, run the check code (in lambda function):
const { FOO } = process.env;
exports.lambdaHandler = async (event, context, callback) => {
console.log(FOO);
};
The output is:
2019-02-22T08:29:05.714Z cde21239-628f-4a79-b046-6a14f177f59e $NODE_PATH
I just rewrite the whole NODE_PATH to be (my custom library path):/opt/nodejs/lib:/opt/nodejs/node8/node_modules/:/opt/nodejs/node_modules:/var/runtime/node_modules
the default value of NODE_PATH is explained there:
https://docs.aws.amazon.com/lambda/latest/dg/current-supported-versions.html
I'm currently learning and toying with Node.js and Express.js and I was wondering what is the proper or most accurate way to use/access a variable depending on environment ( production|development|test ) in client/index.html ?
Typically I would like to use a different Google Analytics code in production and in development environment.
Currently I'm going to investigate/test two solutions :
using grunt to inject relevant code in client/index.html
using a variable set in /server/config/environment/[production|development|test].js
Is there another options and which one is most appropriate way to do this ?
Both are equal, but the second is a bit easier to maintain. You can also pass this value as a URL param in DEV mode (e.g. ?code=123) and skip in production for using a hardcoded constant.