Q: instructions regarding assignToProcessEnv unclear

[leaumar]

On a project I'm adding dotenv-extended to, we're using assignToProcessEnv for the first time (we kept values separated before). This doesn't seem to be working however, values are not assigned to process.env. We'd like to rule out user error first, so we double-checked the readme and found this confusing line:

If this is set, you must capture the return value of the call to .load() or you will not be able to use your variables

What does this actually mean? All we can guess is we must const values = dotenv.load(...); (and then just ignore values since the whole point is we want process.env) instead of just dotenv.load(...);, but we don't see how "capturing" the return value this way can make any difference for the values being assigned to process.env during load(). The const isn't fixing our problem anyway. Could you clarify, please? Thanks.

[keithmorris]

Hi @leaumar . Thank you for the note. I just did a quick test and this seems to be working. Here is the simple example:

index.js

const dotenv = require('dotenv-extended');

dotenv.load({
    assignToProcessEnv: true // default
});

console.log(`DB_HOST : ${process.env.DB_HOST}`);
console.log(`DB_USER : ${process.env.DB_USER}`);
console.log(`DB_PASS : ${process.env.DB_PASS}`);
console.log(`SHARE_URL : ${process.env.SHARE_URL}`);

And here is the .env file:

# .env file
DB_HOST=localhost
DB_USER=databaseuser-local
DB_PASS=databasepw!
SHARE_URL=http://www.example.com

The result of this shows the variable in .env in process.env. Note I tested this on Node 10, 12, 14, and 16.

Console output:

DB_HOST : localhost
DB_USER : databaseuser-local
DB_PASS : databasepw!
SHARE_URL : http://www.example.com

Which version of NodeJS are you using?

Regarding the documentation. You are correct, this needs to be updated as the intention was that you won't be able to use them from your own javascript variable but you can use them from process.env

Can you please verify from the example above?

[leaumar]

I'll be able to test on tuesday (work project), but I can share that it's running on node12 via ts-node and yarn 3.0.2 (pnp enabled).

[leaumar]

I found the problem. Apparently we just got the pwd wrong (it's a multi-module project), we used env.properties when the right path was ../../env.properties.

Now my ticket becomes more of a feedback about dotenv-extended's behavior though.

I have the following configured:

path: "env.properties",
defaults: "env-defaults.properties",
schema: "env-schema.properties",
errorOnMissing: true,
errorOnExtra: true,

I've now learned that this code will not throw or log anything if the mentioned files cannot be found. You have to add silent: false to get a console warning about the 3 missing files.

Would it not make more sense for dotenv-extended to log a warning (or throw an error) when schema cannot be resolved, regardless of silent? I understand .env files are optional generally, and you could say the same of the defaults file in most of the same cases (well, it's 50/50 between personal defaults and project defaults), but surely the schema file is a project constant, virtually always version controlled, that shouldn't be able to silently fail when validation is clearly demanded? It's quite unexpected for an explicitly set failsafe to be failquiet itself in an expectable error case.