1.2.0 breaks serverless interpolation

[otbe]

Hi there,

I love your plugin and I use it for my current pet project. I guess something has broken in the last version. This works in 1.1.5

custom:
  dotenv:
    path: .${self:provider.stage}.env

It will load stage specific files like .dev.env.
In 1.2.0 it can't find the file anymore. envPath is just .${self:provider.stage}.env. I think this related to change when the plugin loads the env file.

Thanks!

[colynb]

Yeah it turns out that I accidentally introduced a breaking change. There's an issue where I couldn't do variable interpolation on the provider section like when you want to use an env var for setting the region. The fix for that introduced a chicken and egg problem that I need to fix.

…

On Tue, Aug 7, 2018 at 2:54 PM Benjamin Otto ***@***.***> wrote: Hi there, I love your plugin and I use it for my current pet project. I guess something has broken in the last version. This works in 1.1.5 custom: dotenv: path: .${self:provider.stage}.env It will load stage specific files like .dev.env. In 1.2.0 it can't find the file anymore. envPath <https://github.com/infrontlabs/serverless-dotenv-plugin/blob/master/index.js#L21> is just .${self:provider.stage}.env. I think this related to change when the plugin loads the env file. Thanks! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABACJHQPNO7Vm9hQIqaQkoNUwwHelqSuks5uOgyugaJpZM4Vy84r> .

[slavaguzenko-vicinity]

@colynb I think restoring hooks in the constructor should fix the problem:

// this.loadEnv()
this.hooks = {
  "before:offline:start:init": this.loadEnv.bind(this),
  "before:offline:start": this.loadEnv.bind(this),
  "before:invoke:local:invoke": this.loadEnv.bind(this),
  "before:deploy:resources": this.loadEnv.bind(this),
  "before:deploy:functions": this.loadEnv.bind(this),
  "before:package:initialize": this.loadEnv.bind(this),
}

[colynb]

Hi @otbe - I've included an update to master branch with a new feature that I think resolves this issue. I have not published it to npm yet so if you wanted to try it out, just clone the repo. In a nutshell, you can control which env file is loaded based on what the environment is set to. You can set environment one of two ways: by setting NODE_ENV or passing in the --env option in the sls command. I've updated the README with more detailed instructions: https://github.com/infrontlabs/serverless-dotenv-plugin#automatic-env-file-name-resolution

[otbe]

Hi @colynb

thanks for the update. 👍
Im not quite sure if this is a way I would like to go. We use many "stages" that are all build with NODE_ENV=production (configured by webpacks mode). So all artifacts are build in "production" mode and deployed with slightly different .env files for each stage. I dont know if there are any sideffects by setting NODE_ENV to something like "stage1" even if its set to "production" by webpack internally. 🤔

Any thoughts?

[colynb]

I love hearing about your use case, it helps a lot. I anticipated that some devs will not be able to set NODE_ENV for whatever reason so I included the "--env" option to the command line. Conceivably you could do something like "NODE_ENV=production sls deploy --stage abc --env abc". This will look for a file called ".env.abc". Would that work for you?

…

On Tue, Sep 25, 2018 at 1:14 AM Benjamin Otto ***@***.***> wrote: Hi @colynb <https://github.com/colynb> thanks for the update. 👍 Im not quite sure if this is a way I would like to go. We use many "stages" that are all build with NODE_ENV=production (configured by webpacks mode). So all artifacts are build in "production" mode and deployed with slightly different .env files for each stage. I dont know if there are any sideffects by setting NODE_ENV to something like "stage1" even if its set to "production" by webpack internally. 🤔 Any thoughts? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABACJMauwKNB3v-G0WWQbPFNJqfdHJMLks5ueeXlgaJpZM4Vy84r> .

[otbe]

Oh 😱
Sorry I totally misinterpreted that part. Yes I think this should be fine for us :)

[colynb]

Excellent! Could you help me make the documentation be more clear?

…

On Tue, Sep 25, 2018 at 10:16 AM Benjamin Otto ***@***.***> wrote: Oh 😱 Sorry I totally misinterpreted that part. Yes I think this should be fine for us :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABACJHhX3-IoeJXetJFRQ23MFggU5UHrks5uemUEgaJpZM4Vy84r> .

--

--- *"A man who dares to waste one hour of time has not discovered the value of life." -- **Charles Darwin*

[otbe]

Dont know :/
At a first glance I thought --env is an alias to set NODE_ENV and I skipped the rest of the docs. But its mentioned quite well that --env should be used if you cant set NODE_ENV. So this should be fine 🤔