Hi, thanks for the PR!

I think it would be best to avoid introducing a behavior change for existing users. How about creating a new function, such as numLevelColor() or bunyanLevelColor(), instead?

Thanks for your reply.

How about creating a new function, such as numLevelColor() or bunyanLevelColor(), instead?

If you tail two containers simultaneously, one which uses string levels, and one which uses numeric levels, how could one solve that if there are different color functions with the current behavior of levelColor? I haven't been able to catch the error thrown when the type doesn't match so that it could fall back to a numeric level parsing.

If adding a bunyanLevelColor and if levelColor could be changed to be more lenient this should at least be possible, right? {{or (levelColor $d.level) (bunyanLevelColor $d.level)}}. If something similar can be achieved with the current behavior of levelColor I would be happy with that, otherwise, I want to suggest this behavior change.

Edit: And by "this behavior change" I don't mean what's currently in the PR. I like splitting the color functions but to enable versatility it would be good if levelColor does not throw an error.

If adding a bunyanLevelColor and if levelColor could be changed to be more lenient this should at least be possible, right? {{or (levelColor $d.level) (bunyanLevelColor $d.level)}}. If something similar can be achieved with the current behavior of levelColor I would be happy with that, otherwise, I want to suggest this behavior change.

How about calling bunyanLevelColor() before levelColor(), instead of changing the current behavior of levelColor()? This approach is more flexible because we could add another level color function such as log4jLevelColor() in the future.

for l in 10 20 30 40 50 60 70 \"debug\" \"info\" \"warn\" \"error\" \"fatal\";
  do echo '{"level": '$l', "msg": "A message"}'
done | \
dist/stern --stdin \
  --template='{{with $d := .Message | parseJSON}}[{{or (bunyanLevelColor $d.level) (levelColor $d.level)}}]  {{$d.msg}}{{end}}{{"\n"}}'

		"bunyanLevelColor": func(level any) string {
			var lv int64
			var err error

			switch value := level.(type) {
			// tryParseJSON yields json.Number
			case json.Number:
				lv, err = value.Int64()
				if err != nil {
					return ""
				}
			// parseJSON yields float64
			case float64:
				lv = int64(value)
			default:
				return ""
			}

			switch {
			case lv < 30:
				return color.New(color.FgMagenta).SprintFunc()(lv)
			case lv < 40:
				return color.New(color.FgBlue).SprintFunc()(lv)
			case lv < 50:
				return color.New(color.FgYellow).SprintFunc()(lv)
			case lv < 60:
				return color.New(color.FgRed).SprintFunc()(lv)
			case lv < 100:
				return color.New(color.FgCyan).SprintFunc()(lv)
			default:
				return strconv.FormatInt(lv, 10)
			}
		},

Yeah, sure we can go with that. I just want to point out a couple of things.

• I'm not sure I understand the reason for keeping the current levelColor behavior. The error causes the log line to be discarded which seems undesireable to me.
• Having bunyanLevelColor fall back to an empty string creates a behavior difference between it and levelColor although as a user I would expect them to function similarly.
  • E.g. this {{or (levelColor $d.level) (bunyanLevelColor $d.level)}} and this {{or (bunyanLevelColor $d.level) (levelColor $d.level)}} will behave differently even though I would expect the outcome to be the same. Feels like arcane knowledge (which I can try to add to the README).

I'll make the changes, but do let me know if you change your mind. 👍

I'm not sure I understand the reason for keeping the current levelColor behavior. The error causes the log line to be discarded which seems undesireable to me.

I have no objection to changing the levelColor argument type to any (interface{}), as long as backward compatibility is maintained. I missed your edited comment, so I misunderstood that you wanted to add an error return value, which would break backward compatibility.

Ok, cool. 👍 Even adding the error return value doesn't affect the user. The template engine swallows it and prints it. But I'll stick with the single string return.

All done, let me know if you want to change anything.