-
Notifications
You must be signed in to change notification settings - Fork 588
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
[ShellScript] Apply to .env #3496
Conversation
This commit makes us apply shell script syntax to `*.env` and `.env` files. These files are commonly used to store environment variables to be sourced or loaded otherwise, in shell syntax, often a simple subset of it.
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.
Make sense to my experience.
@@ -24,6 +25,7 @@ hidden_file_extensions: | |||
- .bash_profile | |||
- .bash_variables | |||
- .bashrc | |||
- .env |
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've also seen .env.local
for environment variables which are only sourced for the local development environment. I'm not sure how common it is and whether it would be worth adding this as well?
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.
No real opinion here, but if we go that route, other similar candidates for consideration would include .env.test
, .env.ci
, .env.dev
, .env.development
, .env.stg
, .env.staging
, .env.prod
, and .env.production
.
I suppose something like .env.*
does not work here?
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 suppose something like
.env.*
does not work here?
No.
It's not "real" ShellScript, though: |
True. The linked examples are just some implementations, there are more, and there is not a single source of truth for these files. In absence of a dedicated syntax, in my opinion and experience they're in practice either actual shell syntax, or close enough that this association makes sense. Even if there was a dedicated syntax, I'm not sure it would do better than ShellScript. |
https://packagecontrol.io/packages/DotENV Maybe personally I won't call this one is better since I've some dedicate coloring rules for the built-in Bash syntax to have Bash looks great already.
|
If adding more than 1, also consider BTW that's an example of where the files truly are Bash scripts. |
I am uncertain whether we should add too common file extensions to core packages as it is easy to add custom extension bindings via "Always open with..." while its harder to get rid of those which are already pre-defined. |
To be fair, my use case is to get env files colorised by bat, and I just submitted the change I planned here for consistency. Turns out I hadn't done my homework and they were actually already partially done in bat (using DotENV), so I submitted sharkdp/bat#2356 (and zaynali53/DotENV#17) instead. Given that DotENV exists and is apparently quite popular, it might be prudent to skip doing this here. Leaving open in case there are other opinions, but I won't pursue this further. |
This commit makes us apply shell script syntax to
*.env
and.env
files. These files are commonly used to store environment variables to be sourced or loaded otherwise, in shell syntax, often a simple subset of it.