gyozatech / noodlog Goto Github PK

User Story

As a developerI want to cover more test cases for colors in order to increase code coverage.

Add the automatic changelog to the project.

We want to have badges in the README.md file through the github actions.
Some interesting badges could be:

• build
• test coverage
• static code analysis analysis

Add templates for:

• Feature request
• Bug Report

User Story

As a developer, I would like to make some enhancements to Colors.

Detailed Description

The proposed enhancements are as follows:

• move Color struct and its methods to log_struct.go file where all the structs of the library are contained. (Even if it's very contextual to have it in color.go file)
• if Color struct and its attribute Code are only reachable from the internal of the noodlog package, change to lowercase letters (color, code). If only Code can be private, it would be the only one to be changed lowercase.
• if we can use a default code color, change the color.code from pointer to string. This way we can avoid using the function ToCode() in order to get its string value, but we can access directly with color.code instead of color.ToCode(). If it's not possible to remove the pointer and to delete ToCode() function, evaluate if it's possible to use lowercase toCode().

User Story

As an operator, I would like to get a DateTime formatted according to my needs.

Detailed Description

Maintain the present formatting as default and allow user customization in order to vary the format, consider the timezone too.

User Story

As a user, I would like to get higher performance for logging.

Detailed Description

Try to substitute classic "encoding/json" marshalling/unmarshalling which uses reflection, with a faster json library (i.e. https://github.com/mailru/easyjson)

User Story

As a user, I would like to create an instance of my logger to prevent using a global set of functions.

Detailed Description

By having a logger with a set of global functions and settings we can have concurrency issues, mostly in tests.

Create a struct Logger and move all the configs and behaviors on this object.
Also, tests and documentation must be updated after this deep refactor.

Now you can enable or disable the ObscureSensitiveData functionality whose check is applied to all log records when enabled.
It slows down the execution time even when you log a simple record.
Extract and make ObscureSensitiveParam public, in order to give the possibility to choose to disable the functionality and using it only when needed.
This could be done this way:

log.SetConfig{ &log.Configs{
         ObscureSensitiveData: log.Disable,
         SensitiveParams: []string{"password"},
     }
}

And then:

log.Info(log.ObscureSensitiveData(myrecord))

This way the feature remains disabled by default but used only when needed.

The regex used to obfuscate sensitive data nowadays works only on string parameters.
Extend the regex or add a new regex in order to get also data without double-quotes.
In that case, try to figure out if null is a better value for boolean, numbers in place of "**************" used for strings.

User Story

As a developer, I would like to redirect Error, Fatal, Panic logs to standard error instead of standard output.

Detailed Description

Create optional configs to perform the routing logic

EnableStdErr()

Take inspiration from:
https://www.systutorials.com/how-to-print-a-line-to-stderr-and-stdout-in-go/

User Story

As a developer, I would like to have a benchmark for noodlog performances.

Detailed Description

It's also possible to compare noodlog with logrus, because it solves similar problems and has similar performances.

Anything else

Keep in mind that enabling sensitive data obscuration, colors, pretty printing is more cost computational than not using these confs.

Keep also in mind that printing a JSON or an Object is more cost computational that writing a simple string record.

User Story

As a developer, I would like to have code coverage for this project.

Detailed Description

Adds codecov for this project.

Bug description

The log messages don't go to next line.

How to reproduce

Just check the logged messages

Environment

• Go version 16+
• OS and Architecture: any

Anything else

Hint: change the fmt.Fprintf() function into fmt.Fprintln() into logger.go -> printLog function.

Bug description

The test TestSimpleLogger is a bit flaky. We must resolve the flakiness.

How to reproduce

Run the tests without cache and you can see the test can go both green and red.

Currently, in the README is possible to see an example of a colorized pretty-printed output.
This is very cool, although it would be useful for someone stumbling upon this library knowing what's the default behavior without any of the configured parameters.

Sometimes it's useful to print everything on a single line and let the use possibly format the output, and some people would look for that specific feature first

Good stuff! 👍

User Story

As a developer, I would like to have the possibility to choose to redirect all logs in a file (one file for the day) in place of standard output.

Detailed Description
Add a setting to define filename, log rotation, etc. and switch the logic when needed.

Beyond the colors defined in the color.go file, create a logic to define a custom RGB color for a specific log level.