Why is local environment loaded when JETS_ENV_REMOTE=1?

Jets
1

Hi Tung (and other members of the community),

First off, thank you for building Jets, it’s exactly what I’ve been looking for.

I have a question about the behavior of the .env files. When JETS_ENV_REMOTE=1 is set, why is .env.development.local still loaded?

  def dotenv_files
    files = [
      root.join(".env"),
      (root.join(".env.local") unless Jets.env.test?),
      root.join(".env.#{Jets.env}"),
      root.join(".env.#{Jets.env}.local"),
    ]
    files << root.join(".env.#{Jets.env}.remote") if @remote
    if ENV["JETS_ENV_EXTRA"]
      files << root.join(".env.#{Jets.env}.#{ENV["JETS_ENV_EXTRA"]}")
    end
    files.compact
  end

I want to be able to deploy dev to AWS to see how my code works with a real DynamoDB but still be able to run it locally against DynamoDBLocal, without having to change dynamodb.yml. I tried using DYNAMODB_ENDPOINT in .env.development.local but then there’s no way for me to unset it in env.development.remote.

Am I doing it wrong?

2

Thanks for the report. Didn’t consider the .local file when the JETS_ENV_REMOTE concept was added. Can see how it’s unexpected behavior that Jets loads the local file too when JETS_ENV_REMOTE. Will dig into it in time. Happy to also consider PRs.

3

Thanks, I’m happy to hear that I had properly understood the intended behavior from the docs. I’m not just doing it wrong, yeah! :smile: I’ll create a PR.

4

Is it possible that this introduced a bug in that if Jets::Resource::Lambda::Function::Environment.env_properties is called when local is present (i.e. polyfun), then .local files are ignored?

5

It’s possible. Jets::Resource::Lambda::Function::Environment.env_properties explicitly sets @remote = true. So, it’s now normal that .local files are ignored.

The current behavior is that .local and .remote files are mutually exclusive, i.e., only one set is loaded. If you want a variable to be loaded in both local and remote environments, put them in .env, .env.development, .env.production, etc.

Do you want to propose a better idea of how it should behave?

6

I guess the problem isn’t that they are mutually exclusive, it’s that the .env.development.local is not loaded at ALL if we’re in a polymorphic function, even if we are local. I’m not sure about why env_properties is forcing remote to be true if JETS_ENV_REMOTE != 1?

What about inside Jets::Resource::Lambda::Function::Environment.env_properties

      env_vars = Jets::Dotenv.load!(truthy?(ENV['JETS_ENV_REMOTE']))

or if it needs to be true even when the variable is not set (like when the code is actually running on lambda)

      env_vars = Jets::Dotenv.load!(truthy?(ENV['JETS_ENV_REMOTE']) || !!ENV['AWS_LAMBDA_FUNCTION_NAME'])
7

Unfortunately, I’m also not sure why env_properties is forcing remote. I’ve never looked closely at that code.

I think you’re right, it should check JETS_ENV_REMOTE or check whether it is running on lambda.

Could you create a PR? @tung will be able to review it and give his feedback.