Compatility with Serverless Framework 3.0.0+

[neverendingqs]

As you may know, starting at 3.0.0, the Serverless Framework will resolve all ${env:} variables before any plugins are created due to a revamp of their variables engine. This means this plugin will no longer be able to inject environment variables into the Serverless environment to be used inside any Serverless YAML files, although it conceiveably is still useful for loading environment variables for other plugins. See the FAQ in the README for details.

The plugin can continue to load variables inside your dotenv files into every function's environment.

There is a simple solution for mimicking what this plugin does in Serverless 3.0.0+, as demonstrated in https://github.com/neverendingqs/serverless-dotenv-example.

Questions:

• Is there value for you in continuing maintenance of this plugin?
  • If so, please 👍 this post and/or reply below.
  • If not, please 👎 this post and/or reply below.
• What are your thoughts with the changes in Serverless Framework 3.0.0+?
• Is there anything you would like to see in light of the new variables engine?

Side note: the new variables engine is already active in Serverless Framework 2.26.0+. However, if it fails to resolve all variables, it will fall back to the previous version of the variables engine, which is why this plugin will continue to mostly work (see FAQ for how 2.26.0+ has affected some things).

[neverendingqs]

I am also thinking of holding off on v4 of this plugin, even though it introduces safer defaults. You can still use them by setting v4BreakingChanges to true.

Alternatively, I might release v4, but leave v4BreakingChanges in so users can continue to use it if they want to undo the breaking changes introduced in v4.

[medikoo]

@neverendingqs great thanks for those comments, and all the insight!

Below I share my view as of Serverless Framework maintainer:

This means this plugin will no longer be able to inject environment variables into the Serverless environment

Technically those variables are now automatically injected into environment by the Framework (assuming dotEnv: true setting in v2, and with v3 it'll happen unconditionally).

The difference here is, that Framework has different rules towards resolving dotenv files specific to given environment.

In Framework either .env file is loaded or .env.<stage> file (if it's provided for given stage), and only single flie is loaded. Note it is per dotenv package recommendations.

In general Framework support for .env reflects the intention of dotenv package authors in how this functionality should be used:

• Environment variables are loaded as first thing in a process
• Variables only from one .env file are loaded
• No other side effects are introduced

---

When this plugin is concerned, I would probably focus on configuration of environment variables for lambdas, as that Framework doesn't provide, and leave loading of environment variables into the process to the Framework

Plugin via some configuration option could take name of env variables to load for lambdas. Still if it'll be just about that, the more accurate name for the plugin would be: serverless-lambda-env-plugin

As a side note, technically plugin will be able to work the way it worked, once support for extensions is introduced, as extensions will be loaded at very early phase (before configuration and variables are resolved). Still once support for .env will be baked into Framework, additional handling of .env files feels controversial.

[stephenbawks]

Is there any thought to be able to pass in a list via ${env:} variable in my env file so I am not having to define many env variables. Example for something like audiences on an API Gateway:

    events: # The Events that trigger this Function
      - httpApi: # HTTP API endpoint
          method: GET
          path: /dostuff
          authorizer: # Optional
            name: auth0authorizer # References by name authorizer defined in provider.httpApi.authorizers section
            scopes:
              - ${env:API_SCOPES}

And then in my env file have it be something like this:

API_SCOPES=[read:stuff,write:stuff,delete:stuff]

[medikoo]

Environment variables are technically limited to be just strings, they cannot be lists.

Having that, I think best to solution would be to have some sort of transformation function that will convert string that contains comma separated tokens into an array. Framework doesn't provide one, but please propose it in Framework issue tracker, I think we will be open for such addtion

[medikoo]

@neverendingqs we've actually decided (internally) to revert from deprecation notice, and in v3 we will keep very same behavior as it's in v2 (.env files will be loaded by the Framework only if useDotenv: true setting is set).

The reasoning is that we're worried to break for users which already use .env files to configure the environment for Lambdas (not service deployments).

PR that removes the deprecation in v2 will be introduced in next days

[mnapoli]

Following the update above, here is a proposal to update the README: #183