New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set dotenv_config_* vars via env var #354
Conversation
Now `dotenv_config_*` can be supplied in a system env var instead of in CLI command. Helps some IDEs that get confused with the CLI option like WebStorm/IntelliJ. WebStorm’s application of those command line config options was resulting in node trying to load them as additional npm modules rather than simple argv options that dotenv would consume.
@motdotla My tests pass locally, I'm not sure what the problem is with the failed build here, I'm not understanding the reported problem. |
As I mentioned in #351, what problem is really being solved? |
@maxbeatty Thanks for taking a look! I'm not too sure if #351 is solving the same problem or not, it's hard to tell. What I know is that while passing the My IDE has some nice features that enhance mocha testing. As such, you can configure how to run the mocha tests from within the IDE. You have to tell it which node arguments to send, which environment variables, the working directory etc. The problem, is that when I put
as the node arguments, it tries to treat all of that above as part of the --require value. My fix allows dotenv to look in argv and then in environment variables. It allows me to then put the |
@maxbeatty I took a closer look at #351. He's trying to solve a different problem where variables meant for the dotenv library conflict with other apps that receive (argv) arguments that they don't expect and then complain about. I think he's saying that if variables destined for dotenv were supplied via environment variables (at least optionally), then they wouldn't conflict. I gather that in his case Jest is complaining about the unknown argument. In my case it's my IDE that isn't treating the dotenv variable as an argv variable, rather it's treating it as a node value of the --require flag; solved by use of environment variables. Note, I still like your original argv version – I prefer it and use it in my npm scripts but I want this workaround I created for situations where it's incompatible. I also included additional documentation to support this in the readme in this PR. Let me know if you have any more questions, I do think this fix would help with #351. |
@maxbeatty further, this is what I get when I do it the argv way via my WebStorm IDE:
|
@maxbeatty Can you help me see what the failed unit tests are complaining about? The tests pass for me locally |
FYI, here's my local success with the same version of node that appveyor CI is dying at without much explanation:
|
Node 6 didn’t support spread operator on objects, only arrays. Later versions of Node do support this FYI. Replaced with older syntax
lib/env-options.js
Outdated
/* @flow */ | ||
|
||
module.exports = { | ||
encoding: process.env.dotenv_config_encoding, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let’s use uppercase to match our existing documentation as well as Node’s official docs. Also, a simple unit test will help with integration tests.
README.md
Outdated
@@ -65,6 +65,9 @@ The configuration options below are supported as command line arguments in the f | |||
$ node -r dotenv/config your_script.js dotenv_config_path=/custom/path/to/your/env/vars | |||
``` | |||
|
|||
Note, some IDEs like Webstorm and IntellJ might have trouble properly passing `dotenv_config_path` to node. This does not impact command line use, just when configuring run options within the IDE. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let’s scrap this IDE-specific stuff and instead expand the existing docs to explain how to use new env vars. Examples outlined here would be a good start
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be helpful for those with IDE problems to mention something like, "If your IDE is having trouble passing the CLI config arguments like dotenv_config_path
you can use environment variables instead (linked to that section)". It will save someone time, I'm sure. We don't have to mention any specific IDE this way. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be better to take IDE-specific questions to StackOverflow or other support forums. Write a blog post about how you fixed your issue. Those help people the most.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I'll do that and make the readme more generic
config.js
Outdated
@@ -2,6 +2,6 @@ | |||
|
|||
(function () { | |||
require('./lib/main').config( | |||
require('./lib/cli-options')(process.argv) | |||
Object.assign({}, require('./lib/env-options'), require('./lib/cli-options')(process.argv)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let’s add some integration tests to verify behavior that documentation outlines
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added :)
to avoid more back and forth comments, I opened #355 based on this with what I had in mind |
my pr works, your pr works |
Now
dotenv_config_*
can be supplied in a system env var instead of in CLI command.Helps some IDEs that get confused with the CLI option like WebStorm/IntelliJ. WebStorm’s application of those command line config options was resulting in node trying to load them as additional npm modules rather than simple argv options that dotenv would consume.