Current behaviour
When an input string contains an LFS colour code e.g. ^1, it is left intact, so the output string is also ^1.
When an input string contains ^^1, the first two ^ are un-escaped as ^, so it is decoded as ^1, which produces the same output as the case above.
This means there is no way of knowing if the original input string was coloured or contained a literal ^ character with a single digit after it.
This behaviour is covered by the unit tests:
|
expect(parseLFSMessage("^1")).toEqual("^1"); |
|
expect(parseLFSMessage("^^1")).toEqual("^1"); |
Expected behaviour
The parseLFSMessage function could parse the LFS colour codes into object tokens and return them in an array. Then the consumer program would decide how to handle the colours - strip them, convert them into HTML etc.
Example:
const tokens = parseLFSMessage('^1Hello^2World^^3Bye')
console.log(tokens);
[
{
string: 'Hello',
color: 'red',
},
{
string: 'World^3Bye',
color: 'yellow',
},
]
Current behaviour
When an input string contains an LFS colour code e.g.
^1, it is left intact, so the output string is also^1.When an input string contains
^^1, the first two^are un-escaped as^, so it is decoded as^1, which produces the same output as the case above.This means there is no way of knowing if the original input string was coloured or contained a literal
^character with a single digit after it.This behaviour is covered by the unit tests:
parse-lfs-message/src/__tests__/specials.test.ts
Line 32 in 40930d9
parse-lfs-message/src/__tests__/specials.test.ts
Line 33 in 40930d9
Expected behaviour
The
parseLFSMessagefunction could parse the LFS colour codes into object tokens and return them in an array. Then the consumer program would decide how to handle the colours - strip them, convert them into HTML etc.Example: