| It looks overly complicated compared to other logging libraries. There's too much going on and there are concepts that you need to understand to grasp how the API works before being able to use it. The front page has "everything is configurable", but that doesn't mean much to me since lots of loggers are also configurable. I actually don't know why I would need or want a global store for logs. Usually shipping logs goes to a third party via something like fluentd, unless I'm missing something here. Maybe first understand what problems people are encountering and think about how your library addresses that and convey that on the front page as a start? I can tell you put a lot of love into it, and hope you solve your marketing issues! I've also written my own logging library with a fluid API that does what I feel are common use-cases: - standard logging levels - ability to record metadata - ability to ingest errors - flexible hooks that allow you to add in your own functionality - is meant to be used with your existing loggers (including console.log) and can easily swap to another logger library (like yours if support was implemented) https://github.com/theogravity/loglayer I built it because my workplace was having the issues mentioned at the top of my library and we now use it everywhere at work because of the consistency it provides and the ability to swap out the underlying logging libraries easily. For example, we use pino and roarr logging libraries between our services, and our devs don't interact with them directly, they use loglayer instead which uses them under the hood. We've had some employees leave the company over time and have told me they use it in their workplace too, so I think part of it is get it popular at your job and hope it can spread to others through word of mouth. |
https://adzejs.com/guide/default-terminators.html