Allow dotenv to load multiline strings like Ruby

[nitsujri]

Expected Behavior

dotenv should load multiline environment variables the same way Ruby loads them via CLI.

$ export MULTI_LINE_STR='this\nshould\nload with double escaped new lines'
$ irb
irb(main):001:0> ENV["MULTI_LINE_STR"]
=> "this\\nshould\\nload with double escaped new lines"

What this PR does

Conforms dotenv new line characters to double-escaped \\n like Ruby does.

Previously Raised Issues

• Quoted newline are being escaped #348
• Quoted newline and quote characters are being escaped #272
• Multi-line env variable #406

DANGER

Potentially breaking change to those who rely on multi-line imports to work in this particular way.

Happy to discuss what is the best way to introduce this change, hence the Draft mode.

[bkeepers]

Hi @nitsujri, thanks for the pull request. I agree that the behavior of dotenv should match shell. Would you be up for adding tests for this behavior?

[nitsujri]

@bkeepers Happy to help, what would you like to see in a spec beyond the small modification I did?

Since this is a breaking change, thoughts on a deprecation process? Options I see are:

1. Total version bump
   • Documentation warning & migration guide
2. Minor version bump
   • Add a flag/option to config/initializers/dotenv.rb that switches the two modes.
   • Defaults to old mode.
   • Add deprecation warning and next major version bump will only allow new mode.

Obviously the latter is more desirable, but is a lot more involved.

Thoughts?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nitsujri]

@bkeepers keeping from going stale, any comments?

[bkeepers]

Happy to help, what would you like to see in a spec beyond the small modification I did?

That spec looks good. Additional specs for double quotes and no quotes might be nice to be explicit about the behavior.

Since this is a breaking change, thoughts on a deprecation process?

The current behavior was the only way to make multi-line environment variables for a long time, so I'm sure it's widely used. I know it's a lot more work, but option 2 feels like the right approach to me.

As for implementation, It could be interesting to use an environment variable to opt in to the new behavior. So adding something like DOTENV_NEWLINE_MODE=strict to the top of a .env file would enable the new behavior. The parser would just have to look for that value in its internal hash or in ENV.