Support "useDotenv: false"

Serverless Framework
1

I am being warned that version 3.0.0 will default to “useDotenv: true”, but when I look at the documentation, this config is going to be removed in version 3.0.0 and .env files will always be included.

Please can you support a false value here? We do not want our local environment files to be included in deployments. They’re excluded from git because they’re a developer’s own config for local tweaking, overriding the SSM parameters used in production.

It looks like I might be able to create an empty .env.production, .env.stage and .env.dev just to avoid this problem but that’s not a sensible solution.

1 Like
2

Hello @DivZero - thanks for feedback. These settings are not going to be passed to Lambda functions during deployment - they’re only locally loaded as env variables. We’ll consider supporting false though :+1:

4

Hello Darksinge,

thanks for sharing. Could you expand a bit more on for what reasons you’d like that to be excluded? Please note that it’s not going to inject your .env variables into Lambda environment, they will be only loaded locally.

5

Hi @pgrzesik, I see that Darksinge removed his comment. I cannot be sure why, but I do wonder if it’s because he realised that it was not a substitute or addition to populating the environment clause of the configuration. This is the mistake I made when I opened this ticket. I wonder if the message isn’t clear enough?

Maybe there needs to be more documentation about what this new feature will do in the help document and how it can be used?

My understanding at the moment is that

  1. It will not populate the environment clause in a configuration file
  2. It will not create environment variables in Lambda
  3. It will expose these variables to serverless so they can be used to augment the configuration file
  4. It has the same effect as setting actual local environment variables

This means that you could reflect them in the configuration if you do want them to be visible to your Lambda:

environment:
   USER:${env:USER}

But if you don’t do that, they will not be used beyond the same scope as actual local environment variables, with the same notes as in the Referencing Environment Variables section of the documentation.

Two points remain:

  • It is currently unclear what the priority order is. If I have a variable that’s both declared in my .env file, and also declared in my actual local environment, which one will be used by Serverless in version 3.0.0?
  • I think allowing this to be false in 3.0.0 would still be vital as a .env file has existing uses. Mixing in this file with serverless will potentially actually break things.
6

Thank you for responding @DivZero :bowing_man: Your understanding is 100% correct :+1: The variables loaded when useDotenv: true is set are only loaded into process.env, which makes them available during variables resolution, etc.

As for the questions:

It is currently unclear what the priority order is. If I have a variable that’s both declared in my .env file, and also declared in my actual local environment, which one will be used by Serverless in version 3.0.0?

We follow the dotenv approach, which never modifies the variables that are already set: dotenv - npm

I think allowing this to be false in 3.0.0 would still be vital as a .env file has existing uses. Mixing in this file with serverless will potentially actually break things.

Do you happen to know workflows that will be broken by the autoloading of .env files? I was thinking about it for quite a while and didn’t find anything concrete, we will consider allowing false for sure, but we want to better understand the actual issues that not allowing to do so might cause.

Thanks once again @DivZero :raised_hands:

7

One example of a use case where I might want to set useDotenv to false is if I’m using serverless.ts config files. Where I prefer loading my variables in my own modules and importing them into the Serverless config. These variables may be loaded from dotenv files, and may not be loaded the same way or using the same conditions as Serverless. So we (my script and Serverless) may choose different files.

In my config modules I might do some checking and verification on the environment. I can potentially verify both that things are set and that things aren’t set. I may also (though I probably wouldn’t recommend it) change the environment into something that is “valid” let’s say I need to remove an environment variable due to some condition.

Basically this means that my environment, once Serverless actually starts deploying (or my application starts locally), may be different to what it was after I verified it. Which to me seems like a potentially huge problem.

8

Our use case for setting useDotenv to false is that we have local scripts in the project directory that use .env and we have separate configuration for our serverless deployments. We’d prefer to keep these separate so our offline scripts don’t interfere with deployed code.

The local scripts and the deployed lambda functions share code and target the same production environment but have some differences in configuration we would like be able to keep separate.

9

Hello :wave:

We’ve decided to skip making it a default from next major and removed the deprecation. If you don’t want to use it, simply do not set useDotenv property.