Neat. It looks like it's more focused on the visual side of things since the screenshot shows two different ways to visually output the results?
I wrote a universal logger that we've been using for our production systems for years that piggybacks on top of bunyan / console / etc. It's pretty much an abstraction layer that provides more structure to logs.
It allows us to easily swap between different logging libs without having to change our entire codebase. For example, we originally started with roarr then eventually migrated to pino, and it was just a few lines of re-config to do so with loglayer.
You use the existing config of your logging library and just feed the instance of it to loglayer.
Looks like a cool project, and props for making it universal for all runtimes. A few pieces of feedback:
1. I don't understand the use case for emojis. If I'm using a logging library in production it's so I can pipe my structured logs into an observability tool. Do emojis provide value in this case?
2. Consider including timestamps by default and adding a config option to remove of needed. I personally can't think of a time where I wouldn't want timestamps in my logs.
Lastly a question: Just because other loggers don't claim to be universal, do they actually break on Deno/Bun?
Also, on the topic of timestamps, some of the formatters do have them on by default. The pretty formatter which is mostly for dev does not because its not as necessary. I hope that helps explain that decision :)
As for emoji's, they are off by default and are really only for dev with the pretty logger. You are right in that you probably would not want them in production. You would probably use a different formatter like "standard" or "json" anyway which doesn't allow them.
That makes sense! This is obviously just my preference, but in both cases I would prefer this to be a config option, so I could control it e.g. by an environment variable. Local dev? Probably don't care about timestamps and probably would enjoy emojis. Production? Absolutely need timestamps and probably don't want emojis. I realize this is a significant API change, but just wanted to share my thoughts.
It is actually also a config option that can be passed to the setup function. Many of the modifiers actually just change the config value under the hood. All production formatters have timestamps by default, only pretty does not so it shouldn't be anything you need to worry about. You can also set timestamps globally in the setup function.
They may or may not break on Deno or Bun, but most will not work in the browser or if they do they are severely limited in functionality. This library was actually born out of my frustration with trying to generate logs and transport them from the browser. Plus, in my past experience, it was a bit of a pain to use older logging libraries with new SSR frameworks. They also mostly have poor, bolted-on typescript support.
> Adze is universal. This means that Adze will "just work" in all of your environments
I'm not sure what this means. console.log is also universal (at least for the platforms mentioned), do you mean that client side logs are shipped to the server?
It's universal meaning it works in the web browser and the backend without any configuration. All other loggers work in one or the other, or if they work in both the functionality is severely limited. Winston and Bunyan only work server side because they use node fs streams. Pino is primarily designed to be a server side library, but it can run in the browser by using browserify and using limited funcionality.
Of course console methods are universal. This library isn't providing console methods, it's providing enterprise/production level functionality on top of the console.
If you want to use Winston in Sveltekit or the like, you have to wrap browser checks around parts of it, otherwise it will explode when bundled.
Right, I usually prefer to use the built in console methods with some currying when needed so I might not be the audience. This has worked well enough even for "enterprise" use-cases.
If I may give one suggestion maybe drop the dependency on 'vuepress-plugin-search-pro' (48MB) and maybe 'date-fns' (23MB), that seems like some really large dependencies that might not be required.
First of all, if that's all you need then by all means, keep doing that. If you need any of the following, maybe consider a library:
- First-class TypeScript support (not bolted-on)
- Wraps and extends the entire standard API
- A convenient chainable API
- Log Listeners for capturing log data
- Middleware support for plugins and transporting logs
- Log annotations such as namespaces, labels, and other meta data
- Four formats supported out of the box:
- Pretty - Human readable logs that are easy on the eyes
- JSON - Machine readable logs that are compatible with the Bunyan CLI
- Standard - Human readable stdout logs
- Common - Logs that adhere to the Common Log Format
- Everything is customizable and configurable
- Tools for caching, filtering, and recalling logs
- Support for creating log threads to track data across multiple scopes
- Convenient child logger API's
If you look at the readme you'll see adze is 8kb bundled and gzipped. It's ESM so it has tree-shaking support. It's tiny. The Vue dependency is for the docs.
Install size is 38MB and was 94MB until you moved vuepress-plugin-search-pro to devDependencies (I'm guessing because of my comment?) so even though it might be treeshook to a small size install size is still quite a bit larger to install.
I'm pretty sure all the mentioned runtimes support all the standardized console methods, and it does not mention anything about compatability with more restricted environments like quickjs or embedded js.
Hey, cool project! Will have to try it out next time.
Some design feedback on the site:
> Universal By Nature
The contrast ratio on the headers is really hard to read. I skipped the hero section and began reading at where it said:
> which means it can be executed on the server side or the browser side without any extra considerations. Use it anywhere!
And I totally missed it's a logging library - I was expecting to see a new web framework. My preference would be to put the Simple, Chainable API section before.
It appears I had that mistakenly in the dependencies instead of devDependencies. I'm correcting it now and will release a patch. Thanks for the heads up!
Right now daily file rotation is supported via the @adze/transport-file plugin. Plugins can be made using simple middleware hooks for any of your needs. I'm working on adding more right now for other services like Cloudwatch Logs, Google Logging, Open Telemetry, etc.
Neat. It looks like it's more focused on the visual side of things since the screenshot shows two different ways to visually output the results?
I wrote a universal logger that we've been using for our production systems for years that piggybacks on top of bunyan / console / etc. It's pretty much an abstraction layer that provides more structure to logs.
It allows us to easily swap between different logging libs without having to change our entire codebase. For example, we originally started with roarr then eventually migrated to pino, and it was just a few lines of re-config to do so with loglayer.
You use the existing config of your logging library and just feed the instance of it to loglayer.
https://github.com/theogravity/loglayer
It basically prevents problems like this:
to: A common use case is using loglayer + console initially, then swapping to something like pino later on.Looks like a cool project, and props for making it universal for all runtimes. A few pieces of feedback:
1. I don't understand the use case for emojis. If I'm using a logging library in production it's so I can pipe my structured logs into an observability tool. Do emojis provide value in this case?
2. Consider including timestamps by default and adding a config option to remove of needed. I personally can't think of a time where I wouldn't want timestamps in my logs.
Lastly a question: Just because other loggers don't claim to be universal, do they actually break on Deno/Bun?
Also, on the topic of timestamps, some of the formatters do have them on by default. The pretty formatter which is mostly for dev does not because its not as necessary. I hope that helps explain that decision :)
As for emoji's, they are off by default and are really only for dev with the pretty logger. You are right in that you probably would not want them in production. You would probably use a different formatter like "standard" or "json" anyway which doesn't allow them.
That makes sense! This is obviously just my preference, but in both cases I would prefer this to be a config option, so I could control it e.g. by an environment variable. Local dev? Probably don't care about timestamps and probably would enjoy emojis. Production? Absolutely need timestamps and probably don't want emojis. I realize this is a significant API change, but just wanted to share my thoughts.
It is actually also a config option that can be passed to the setup function. Many of the modifiers actually just change the config value under the hood. All production formatters have timestamps by default, only pretty does not so it shouldn't be anything you need to worry about. You can also set timestamps globally in the setup function.
https://adzejs.com/getting-started/setup.html
https://adzejs.com/reference/configuration.html#user-configu...
They may or may not break on Deno or Bun, but most will not work in the browser or if they do they are severely limited in functionality. This library was actually born out of my frustration with trying to generate logs and transport them from the browser. Plus, in my past experience, it was a bit of a pain to use older logging libraries with new SSR frameworks. They also mostly have poor, bolted-on typescript support.
I enjoyed the punny forestry imagery. Going beyond console.log in a sveltekit app was on my todolist so I’ll try this out.
Puns for the win
> Adze is universal. This means that Adze will "just work" in all of your environments
I'm not sure what this means. console.log is also universal (at least for the platforms mentioned), do you mean that client side logs are shipped to the server?
It's universal meaning it works in the web browser and the backend without any configuration. All other loggers work in one or the other, or if they work in both the functionality is severely limited. Winston and Bunyan only work server side because they use node fs streams. Pino is primarily designed to be a server side library, but it can run in the browser by using browserify and using limited funcionality.
Of course console methods are universal. This library isn't providing console methods, it's providing enterprise/production level functionality on top of the console.
If you want to use Winston in Sveltekit or the like, you have to wrap browser checks around parts of it, otherwise it will explode when bundled.
Right, I usually prefer to use the built in console methods with some currying when needed so I might not be the audience. This has worked well enough even for "enterprise" use-cases.
If I may give one suggestion maybe drop the dependency on 'vuepress-plugin-search-pro' (48MB) and maybe 'date-fns' (23MB), that seems like some really large dependencies that might not be required.
First of all, if that's all you need then by all means, keep doing that. If you need any of the following, maybe consider a library:
- First-class TypeScript support (not bolted-on)
- Wraps and extends the entire standard API
- A convenient chainable API
- Log Listeners for capturing log data
- Middleware support for plugins and transporting logs
- Log annotations such as namespaces, labels, and other meta data
- Four formats supported out of the box:
- Everything is customizable and configurable- Tools for caching, filtering, and recalling logs
- Support for creating log threads to track data across multiple scopes
- Convenient child logger API's
If you look at the readme you'll see adze is 8kb bundled and gzipped. It's ESM so it has tree-shaking support. It's tiny. The Vue dependency is for the docs.
https://bundlephobia.com/package/adze@2.0.10
Install size is 38MB and was 94MB until you moved vuepress-plugin-search-pro to devDependencies (I'm guessing because of my comment?) so even though it might be treeshook to a small size install size is still quite a bit larger to install.
I guess it provides a complete console like API in all cases where some environments offer fewer console methods?
I'm pretty sure all the mentioned runtimes support all the standardized console methods, and it does not mention anything about compatability with more restricted environments like quickjs or embedded js.
Hey, cool project! Will have to try it out next time.
Some design feedback on the site:
> Universal By Nature
The contrast ratio on the headers is really hard to read. I skipped the hero section and began reading at where it said:
> which means it can be executed on the server side or the browser side without any extra considerations. Use it anywhere!
And I totally missed it's a logging library - I was expecting to see a new web framework. My preference would be to put the Simple, Chainable API section before.
Thanks for the feedback!
cool I was looking for something like this, attractive site too
when I install it it seems to depend on vuepress-plugin-search-pro which requires yarn 2 berry. not sure if you are aware this extra hurdle
It appears I had that mistakenly in the dependencies instead of devDependencies. I'm correcting it now and will release a patch. Thanks for the heads up!
You can install 2.0.11 for the fix now!
What transports are supported out of the box? Like file, S3, etc?
Right now daily file rotation is supported via the @adze/transport-file plugin. Plugins can be made using simple middleware hooks for any of your needs. I'm working on adding more right now for other services like Cloudwatch Logs, Google Logging, Open Telemetry, etc.