Reference to env vars sitting outside main config yml causes error

[DavidHe1127]

Error:

 Serverless Plugin Error --------------------------------------

  Cannot create property 'DYANMODB_TABLE' on string '${file(./serverless-env.yml):environment}'

configs:

serverless.yml

service: my-service

plugins:
  - serverless-dotenv-plugin

provider:
  name: aws
  runtime: nodejs8.10
  environment: ${file(./serverless-env.yml):environment}

serverless-env.yml

environment:
  SLS_AWS_STAGE: ${env:DYANMODB_TABLE, 'xxvvv'}

No errors when moving environment to outside the provider. Verified that it's working perfectly when it's located outside provider.

[mgarciadelojo]

The same happens to me. I have different environment files per stage, and quite annoying to see the warning every time I run a serverless command.

[mattia85]

I'm getting the same error, any update about this issue?

[colynb]

No updates, sorry. I haven't had many resources to set aside and look deeper into this. It's a plugin that works fairly well for most people in most use-cases. If you'd like to take a look at the code and see how it could be improved, that would be really helpful.

[Ali-Dalal]

same issue here :(. any idea how to solve this?

update:

I had a look at the code and I figure out the issue.

in index.js
we need to replace lines 74 to 79 with the following:

        let tmpEnvVars = {};
        Object.keys(envVars).forEach(key => {
          console.log(key);
          if (this.logging) {
            this.serverless.cli.log('\t - ' + key)
          }
          tmpEnvVars[key] = envVars[key];
        })
        this.serverless.service.provider.environment = tmpEnvVars;

the idea is this assignment is wong in case enviroment is set to load from different file
this.serverless.service.provider.environment[key] = envVars[key]
and it will cause the following if environment is set to (as an eample ${file(./serverless_variables/environment_variables.yml):${env:NODE_ENV,development}})

[${file(./serverless_variables/environment_variables.yml):${env:NODE_ENV,development}}] = envVars[key] //which is wrong

@colynb can you have a look? if the changes can be applied, I can open a PR.

Thanks

[RaydelMiranda]

You can read from https://www.serverless.com/framework/docs/providers/aws/guide/plugins/#plugins/:

Variable references in the serverless instance are not resolved before a Plugin's constructor is called, so if you need these, make sure to wait to access those from your hooks.

In this case the method loadEnv is being called in the constructor of the plugin, causing the known issue since the references have not been resolved at that point.

[neverendingqs]

Thanks for the investigation!

This plugin does two different things:

1. Load all environment variables defined in dotenv file(s) into the Serverless environment
2. By default, assign all environment variables to provider.environment

Doing 1) in the constructor is handy because it ensures the environment variables are loaded pretty much before anything else can happen.

This bug happens while trying to do 2).

I think the best workaround for this is to manually wire up the environment variables yourself:

custom:
  dotenv:
    include: []

Setting dotenv.include to [] will cause the plugin to bypass any interaction with provider.environment because it will result in envVars being an empty list:

serverless-dotenv-plugin/index.js

Lines 120 to 123 in 2b66c15

	Object.keys(envVars).forEach((key) => {
	this.log('\t - ' + key)
	this.serverless.service.provider.environment[key] = envVars[key]
	})

.

[neverendingqs]

FYI I have updated the README with this issue and the workaround: #108

[RaydelMiranda]

Thanks for the feedback. If I find the time I'll try to find a definitive solution. Would you be willing to accept a pull request on this?

[neverendingqs]

Thanks for the feedback. If I find the time I'll try to find a definitive solution. Would you be willing to accept a pull request on this?

I'm open to a solution, but maybe it's better to discuss it here first. Just looking to avoid a situation where you have a full pull request and a disagreement arises that causes rework 🙂.