Support inline comments

[jonathan-reisdorf]

fixes #524
fixes #545
fixes #156
fixes #484

[PodaruDragos]

Hello. Is there anything that's blocking this one from getting merged?

[motdotla]

@PodaruDragos no, nothing blocking. We are just prioritizing some cleanup and tightening up of the project before this. This will be a major new upgrade.

[motdotla]

@jonathan-reisdorf thank you for this and for your patience. Apologies for the delay. If you end up joining Dotenv Sync, let me know and I will make sure they get you 6 months free for your organization.

[renandecarlo]

This broke using # in the variable itself. Such as:
MSG=Hello, you've got a new order (#%order_n%)

How should I use it now?

[jonathan-reisdorf]

@renandecarlo Yes, unquoted # characters mark now the beginning of a comment. In order to use the character in the value, you now have to put it in quotes, e.g.

MSG="Hello, you've got a new order (#%order_n%)"

[jonathan-reisdorf]

(We could also take into account if there is a space before the # character. E.g. the GNU coreutils' env does that. Then again, I've seen other frameworks/tools behaving exactly as dotenv is now. Let me know @motdotla if you want the # only to mark the beginning of a comment if it's preceded by a space character or if it's the first character, then I'm happy to create a PR for this)

[motdotla]

Thanks @jonathan-reisdorf. Let's leave it as is. That has the least surprise.

Sorry about this breaking your line @renandecarlo, but, as @jonathan-reisdorf mentioned, just put double quotes around it and you will be good to go.

[renandecarlo]

I had to stick with version 13, otherwise it would break my program for everyone already using it without quotes. But that's ok.
I think most comments would have had a space before # though

[motdotla]

Ah darn. As a developer myself I never enjoy getting stuck like that. We'll consider an optional flag where you can switch to an older mode.

When you say all your devs would have to switch, can you elaborate on that? You mean they would each have to update their own .env file locally?

[renandecarlo]

Yes. The example env file shipped with some default values which contained #, like the example above, and those could be changed or not. Everyone would then have to add the quotes to it, otherwise it would break.
Version 13 works just fine for me though.

[Devtronyx]

Thanks @jonathan-reisdorf. Let's leave it as is. That has the least surprise.

Sorry about this breaking your line @renandecarlo, but, as @jonathan-reisdorf mentioned, just put double quotes around it and you will be good to go.

It is still treated as a comment even inside double quotes. I'm on version 14.2.0. And the value represents a password so it's not much I can do about it

[motdotla]

@jonathan-reisdorf can you double check that, please, if you get a chance before I do?

[jonathan-reisdorf]

Thanks @jonathan-reisdorf. Let's leave it as is. That has the least surprise.
Sorry about this breaking your line @renandecarlo, but, as @jonathan-reisdorf mentioned, just put double quotes around it and you will be good to go.

It is still treated as a comment even inside double quotes. I'm on version 14.2.0. And the value represents a password so it's not much I can do about it

See #601 (comment)
Typically the wrapping quotes would be outside of the value

[jonathan-reisdorf]

When you say all your devs would have to switch, can you elaborate on that? You mean they would each have to update their own .env file locally?

@motdotla if @renandecarlo uses dotenv the same way as we are in our organization, there's a .env.example file that's committed to git containing the default values, and developers copy that file to their own local .env which is gitignored.
That way, devs can make local changes to the values without creating unstaged changes potentially containing secrets which they might accidentally commit. The disadvantage to this is that there's usually no migration/syncing mechanism between the two files.

Ah, sorry, just read @renandecarlo's comment where he says they are indeed using example env files 👍

[motdotla]

The disadvantage to this is that there's usually no migration/syncing mechanism between the two files.

Indeed. We've been building out Dotenv Sync to help solve this problem. @renandecarlo you can give that a try. Then you could make the updates to the .env file (adding quotes), and then all your team members would just run dotenv-cli pull to instantly update their local .env file.