Having modules getting direct access to process.env is not a good idea, and modules having their own .env file is an even worse idea.

• .env files should not be added to source control (ie git) because they change with the environment (dev, prod, pre-prod) and sometimes contains sensitive information (like AWS secret keys). So that would require you to paste a .env file each time you install your node_modules making your deployment process more complex.

• The .env file loaded inside your module could merge in unexpected ways with the .env of your root app (remember there is only one process.env).

• Imagine a case where your module would need to behave differently in two parts of your application. How would you override the data loaded via the .env file only in one place?

So in my opinion, your guess is correct: don't put .env in node_modules.

// This is better...
nModule.someMethod(process.env.PARAM1, process.env.PARAM2);

// ...than this
process.env.PARAM1 = '';
process.env.PARAM2 = '';

nModule.someMethod();

Your approach sounds correct and it should work. When you define .env file and use dotenv package, you will be able to access all the variables inside .env in your code. That means that custom made node modules will also be able to access it, and you don't have to pass them anything (you can access them directly with process.env.NAME_OF_ENVIRONMENT_VARIABLE).

SUMERIZE: Create .env file in both A and B, use dotenv package, and then you can access environment variables directly inside the code with process.env.NAME_OF_ENVIRONMENT_VARIABLE (in custom node modules also). You can create constructor (for custom modules) in modules A and B, and just pass process.env.ENV_WHATEVER as a parameters. That is even better approach since your custom module's logic will be independent from the rest of the app (it will depend only on the input).

NOTE: Don't commit your .env to Git since .env usually have some confidential information. The best practice is to create a .gitignore file and add .env in it.

RECOMMENDATION You can keep all your .env files in one centralized place for better management. You can check some password management tools like https://www.dashlane.com/ or https://www.lastpass.com/.

I feel strongly that environment variables are reserved for, well, the environment. This to me implies a few things:

• Inside the code, these variables should be global, i.e., accessed only via process.env.
• They are not passed down to other modules. Certainly it's a good idea to make dependencies customizable with parameters you can pass to the functions they export. But the environment should not be used for that.
• How you load values into process.env is really a question of how you start your programs A and B. I personally prefer systemd services for that which have excellent support for defining the runtime environment. The dotenv package seems more like a crutch, but it's fine from the program's perspective.