Violations¶
Parsing¶
Different error that might happen during file parsing phase.
Names¶
Rules that define how names should be defined.
- class SpacedNameViolation(node, text)[source]¶
Bases:
BaseFSTViolationRestricts to use leading spaces in names variables.
- Reasoning:
This spaces will be removed by the parsing mechanism, but they might cause some confusion to users.
- Solution:
Remove leading spaces.
Example:
# Correct: SOME_KEY=1 # Wrong: SOME_KEY=1
Added in version 0.1.0.
- class IncorrectNameViolation(node, text)[source]¶
Bases:
BaseFSTViolationRestricts to use restricted symbols to define names.
- Reasoning:
By convention we can only use letters, numbers, and underscores to define dotenv variables. Moreover, variables can not start with numbers.
- Solution:
Refactor your file to contain only allowed characters.
Example:
# Correct: SOME_KEY=1 # Wrong: SOME-KEY=1
Added in version 0.1.0.
- class DuplicateNameViolation(node, text)[source]¶
Bases:
BaseFSTViolationRestricts to use duplicate names variables.
- Reasoning:
There is no need to create duplicate variables inside your dotenv file. Since it will be implicitly overridden by the parsing mechanism.
- Solution:
Remove one of the duplicate variables.
Example:
# Correct: SOME_KEY=1 OTHER_KEY=2 # Wrong: SOME_KEY=1 SOME_KEY=2
Added in version 0.1.0.
- class RawNameViolation(node, text)[source]¶
Bases:
BaseFSTViolationRestricts to use raw names without equal sign or value.
- Reasoning:
It does not make any sense to just state some names. It might also break some
.envparsers.- Solution:
Append equal sign to it. So, this would became a declaration of an empty variable. You can also add a value if it makes sense.
Example:
# Correct: KEY=1 OTHER= # Wrong: KEY
Added in version 0.1.0.
- class ReservedNameViolation(node, text)[source]¶
Bases:
BaseFSTViolationRestricts to use of blacklisted names.
- Reasoning:
It does not make any sense to use such names.
- Solution:
Change such names. Or, Add
_at the end, to distinguish it from reserved ones.
Example:
# Wrong: DJANGO_ENV=some_value
Added in version 0.2.0.
Assigns¶
Rules that define how assigns should be made.
- class SpacedAssignViolation(node, text)[source]¶
Bases:
BaseFSTViolationRestricts to write
=signs with extra spaces.- Reasoning:
Valid
shellsyntax requires to write assigns without any spaces.- Solution:
Remove any spaces between the
=char.
Example:
# Correct: KEY=1 OTHER= # Wrong: KEY = 1 OTHER =
Added in version 0.1.0.
Values¶
Rules about writing correct dotenv values.
By convention we do not print values to the output. Since they might contain private values.
- class SpacedValueViolation(node, text)[source]¶
Bases:
BaseFSTViolationRestricts to write values with trailing spaces.
- Reasoning:
These spaces are not guaranteed to be preserved. So, it is better not to rely on them.
- Solution:
Remove trailing spaces from the value.
Added in version 0.1.0.
- class QuotedValueViolation(node, text)[source]¶
Bases:
BaseFSTViolationRestricts to quoted values.
- Reasoning:
Dotenv parser usually strips quotes away, so it is hard to say whether these quotes will stay on a final value, or not.
- Solution:
Remove any quotes from the value.
Example:
# Correct: KEY=1 # Wrong: KEY="1"
Added in version 0.1.0.
- class InvalidEOLViolation(node, text)[source]¶
Bases:
BaseFSTViolationRestricts to use rn (CRLF) end-of-line.
- Reasoning:
Mixing different end-of-line chars can lead to different hard-to-debug problems.
- Solution:
Use n (LF) end-of-line. Another option is to add line text eol=lf to .gitattributes.
Added in version 0.6.0.
Comments¶
Rules that define how comments should be written.
- class SpacedCommentViolation(node, text)[source]¶
Bases:
BaseFSTViolationRestricts to write comment with leading or trailing spaces.
- Reasoning:
These spaces are meaningless and will be removed. So, why would you want to have them?
- Solution:
Remove leading or trailing spaces from the comment body.
Added in version 0.1.0.