♻️ logger/middleware to Eliminate Code Duplication

[Skyenought]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Explain the details for making this change. What existing problem does the pull request solve?

Fixes # (issue)
#2581

Type of change

Please delete options that are not relevant.

• refactor

Checklist:

• For new functionalities I follow the inspiration of the express js framework and built them similar in usage
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation - /docs/ directory for https://docs.gofiber.io/
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• If new dependencies exist, I have checked that they are really necessary and agreed with the maintainers/community (we want to have as few dependencies as possible)
• I tried to make my code as fast as possible with as few allocations as possible
• For new code I have written benchmarks so that they can be analyzed and improved

Commit formatting:

Use emojis on commit messages so it provides an easy way of identifying the purpose or intention of a commit. Check out the emoji cheatsheet here: https://gitmoji.carloscuesta.me/

[sixcolors]

@Skyenought why not move the colors into tags.go and remove the entire conditional check (line 141) from logger.go? Wold have the side benefit of enabling colors on custom formated logs.

[sixcolors]

add //nolint:errcheck // This will never fail here and remove from line 167 to fix linter error

[sixcolors]

@Skyenought why not move the colors into tags.go and remove the entire conditional check (line 141) from logger.go? Wold have the side benefit of enabling colors on custom formated logs.

Looks like TagStatus and TagMethod are already done, so that only leaves TagError which could be refactored to:

		TagError: func(output Buffer, c *fiber.Ctx, data *Data, extraParam string) (int, error) {
			if data.ChainErr != nil {
				if cfg.enableColors {
					colors := c.App().Config().ColorScheme
					return output.WriteString(fmt.Sprintf("%s %s %s", colors.Red, data.ChainErr.Error(), colors.Reset))
				}
				return output.WriteString(data.ChainErr.Error())
			}
			return output.WriteString("-")
		},

Updated: Note, as per next comment, I have seperator and spacing concerns that would still need to be solved depending on error != nil condition.

[sixcolors]

@Skyenought

I've identified an inconsistency in code formatting and error handling. While the default format is [${time}] ${status} - ${latency} ${method} ${path}\n , the current implementation [and current PR] switches to ${time} | ${status} | ${latency} | ${ip} | ${method} | ${path}\n with "logger.go" adding " | " + chainErr.Error() or colors.Red + " | " + chainErr.Error() + colors.Reset (if error != nil) before the line break.

Several issues arise from this:

1. The default format doesn't align with the ConfigDefault format, leading to confusion.
2. Opting for [${time}] ${status} - ${latency} ${method} ${path}\n is not feasible.
3. Custom logger formats behave inconsistently with the default due to TagError in tags.go not addressing spacing or separator differences when error != nil.

For a more coherent approach, I recommend reviewing both "tags.go" and "logger.go" logic to ensure consistent formatting and error handling.

I'd also appreciate input from @ReneWerner87 and @gaby regarding this matter.

[gaby]

@Skyenought

I've identified an inconsistency in code formatting and error handling. While the default format is [${time}] ${status} - ${latency} ${method} ${path}\n , the current implementation [and current PR] switches to ${time} | ${status} | ${latency} | ${ip} | ${method} | ${path}\n with "logger.go" adding " | " + chainErr.Error() or colors.Red + " | " + chainErr.Error() + colors.Reset (if error != nil) before the line break.

Several issues arise from this:

1. The default format doesn't align with the ConfigDefault format, leading to confusion.
2. Opting for [${time}] ${status} - ${latency} ${method} ${path}\n is not feasible.
3. Custom logger formats behave inconsistently with the default due to TagError in tags.go not addressing spacing or separator differences when error != nil.

For a more coherent approach, I recommend reviewing both "tags.go" and "logger.go" logic to ensure consistent formatting and error handling.

I'd also appreciate input from @ReneWerner87 and @gaby regarding this matter.

I agree, the formatting of the logs should be consistent. Specially because some users may be parsing these logs with other tools.

[Skyenought]

@gaby

I changed DefaultFormat to ${time} | ${status} | ${latency} | ${method} | ${path} | ${error}\n.

This is also the fact that the template format, ${error}, is not always available.

[sixcolors]

@Skyenought what do you think about adding an TagIfError that only displays if err != nil and has optional padding and seperators?

[Skyenought]

@sixcolors
I think if you change return output.WriteString("-") to return output.WriteString("") in the last line of TagError and you'll get the effect you're describing, right?

[sixcolors]

@sixcolors
I think if you change return output.WriteString("-") to return output.WriteString("") in the last line of TagError and you'll get the effect you're describing, right?

I was trying to suggest:

1. Introduce a TagIfError tag that conditionally displays ${iferror} only when err != nil. This approach allows for clear and concise logs while ensuring that relevant errors are included.
2. The function could mirror the formatting used in the default logger from logger.go. This consistency would maintain a familiar and user-friendly log structure.
3. To provide even more flexibility, consider enabling optional padding and separators for ${iferror}, eg ${iferror,separator=|,spacing=true}. This would allow users to customize the error presentation according to their preferences.
4. We could eliminate the default formatter code from logger.go and use the tags.go code for all format strings.
5. In practice, this would result in a cleaner and more informative log output. For instance:

${time} | ${status} | ${latency} | ${method} | ${path} | ${iferror,separator=|,spacing=true}\n

[Skyenought]

@sixcolors
I see what you mean. Let me try.

[ReneWerner87]

can we also have unittest for testing this format by injecting a special writer and testing our expectation with and without colors?

i also like to check the color setting inside the tag
which ensures that the format outside remains the same
and then the coloring works not only for the standard format, but for any custom composited format

[ReneWerner87]

closed by #2773