arabold
commented
3 years ago Thank you for explaining your use case in such detail, @theburningmonk .
Some of the reasons that exporting the output variables was removed are:
- In the last version, the value of the environment variables can now be determined and generated even if the project isn't fully deployed yet. This simplifies local testing of Lambdas significantly as you don't have to deploy your function first before you can run a test. When adding output variables, the problem is that you need to deploy first before you can read the values from the output. This is a conflicting paradigm and forces you to deploy a new version before you can even test it.
- The goal of the plugin is to create a local environment that is as close to the remote one as possible. Only that can ensure that your local tests work in a very similar fashion as the deployed version would. Adding additional environment variables that aren't part of the original Lambda risks introducing side effects that can be hard to track down for inexperienced developers.
- The naming of the environment variables generated from output variables wasn't well defined. There's the potential of conflicts with "real" environment variables, amplifying the previous problem.
- By adding support for
!ImportValue,!GetAtt,!Ref, and several conditional and intrinsic functions (!If,!Equals,!Select,!Split, etc.) in the last version, many previously impossible use cases can now be solved in an elegant way.
From what I'm reading in your comment, your main issue seems to be that there's a set of output variables that you like to access locally but don't want to define any environment variables for. Despite I'm not having a use-case for this functionality myself, I'd be happy to accept any PR that adds it back and considers the above issues in a reasonable way. As this understandably might not be a short-term option for you, maybe you can use a second plugin to export all output variables into a secondary .env file? I.e. have serverless-export-env generate the .env based on the actual environment variables and have another plugin create a .env-outputs? Then use dotenv to load that secondary environment file only in your test code. This way it would not affect the rest of the app which I would consider a plus. Thoughts?
In v2.0 the plugin has removed fetching the stack outputs, while I'm not sure what you were referring to when you said it caused more problems than it solved, but it was a very valuable capability.
From some of the changes in 2.0 I guess the use case you have in mind is for capturing env vars for individual functions to facilitate
sls invoke, but another use case I've had for this plugin is to support testing my function code locally before deploying them (what I call "integration tests").For that use case, I'm always capturing all the environment variables (I use a consistent naming convention to the env vars so when two env vars have the same name, they reference the same CFN resource), and there are often times when there are things that I don't want to include as env vars for the functions themselves. For example, when using cognito, I might create a cognito client to use by the test and allows the test to set up new users to test the authenticated endpoints (in what I call "end-to-end tests" even though these tests don't test the client application, which might be a mobile app or a web app, but nonetheless they test the deployed API endpoints to make sure they're working as expected). This cognito client is not necessary for any of the Lambda functions and is used only by the tests, so it's a bit silly to have to add it to some random function (or worse yet, to the
provider.environment) just so I can capture it in the .env file.In some cases, we'd also like to add conditional resources to facilitate end-to-end tests for more event-driven architectures, e.g. creating SQS queues to subscribe to EventBridge buses in dev environments so we can poll the queue to see what messages are sent to EventBridge. It's hard to capture these conditional resources into environment variables, but it's easy to capture them as stack outputs.
There are other plugins that can capture the stack output, but using two plugins that write to the .env file creates other problems (besides just adding more moving parts) such as the fact that each plugin would want to overwrite the whole file. So if I can get this plugin to fetch the stack outputs as well, it'd make life so much easier.
I understand that you've made an explicit decision to move away from doing this in v2, but how about making it an optional behaviour and gate it with another flag like
--include-outputs?