v2: Add `anylogger` support

[Download]

Ulog has a microscopically small footprint of just over 1kB. But we can do better!

anylogger currently has a footprint of just over 500 bytes. We can make ulog depend on anylogger and only add the missing features. This will make ulog the first library with native anylogger support.

Libraries can depend on anylogger instead of on ulog and only add a ~500 bytes footprint shared with all other libraries depending on anylogger. App developers can then plug in whatever logging framework they like. But with ulog depending on anylogger, we can probably beat most other loggers out there in terms of total dependency size. We should be able to stay below 1.5kB total at the app level and finally have a way for all libraries to participate in logging without incurring expensive overhead.

[toddb]

Any update on this? Can't see support in the code base or a branch. Docs over here says:

Because ulog supports anylogger natively, we don't need an adapter

[JackCA]

I'm also confused by this as well. The docs in anylogger mention multiple times that ulog has native support for it. Are we supposed to use a different release?

[toddb]

@JackCA We've forked the relevant repos, made changes and pull requests and are waiting for merges/releases. Until then using the forks until the changes come through. From memory, tiny changes!

[JackCA]

@toddb did you fork ulog? I've only found your anylogger fork

[toddb]

Both under this identity https://github.com/semanticlink

• https://github.com/semanticlink/anylogger
• https://github.com/semanticlink/ulog

[Download]

Hi guys, thanks for your enthousiasm! And sorry that I've been unresponsive for a while. Life happened.
Anyway I'm back on the job with anylogger and ulog. Frankly, I've first made a royal mess of it and then left it out in the cold for way too long and I'm amazed you guys are so patient with it. Thanks!

If you are still interested in these projects, I would urge you to have a look at anylogger as it is now, because I have just released 1.x. It took a long time to get here and I still see some more minor releases coming up but I feel it has been stable API wise for long enough now. Because I want to work very hard to make sure I can stay backward compatible from now on.

I've been talking to the author of log4js. Interestingly he had the same idea as I had for anylogger, but on a smaller scale. He has factored out the public API of log4js into a separate package log4js-api. Anylogger attempts to do the same thing but for any logger.

There are a bunch of adapters that are nearly ready and a bunch more that will probably come in the future. Hopefully at some point the community will pick up the ball and start producing other adapters where needed.

Currently these are working and either already on anylogger 1.x or will be ported to 1.x in the next couple of days:

• anylogger-debug makes anylogger work with debug
• anylogger-loglevel makes anylogger work with loglevel
• anylogger-log4js makes anylogger work with log4js

As mentioned before, I am trying to get ulog to work with anylogger. I think I have been over-ambitious in the feature set. I really want formatters, bad. But I think I will make a release without them first to get 2.x out of the door. You guys deserve to get some stable working software finally because it has been in beta for way too long.

I am also working an an anylogger adapter for pino but I'm having trouble with it so it will probably have to wait until I can get some help on it from someone that is experienced with Pino.

Furthermore, there is a whole different problem set that I think can be solved with anylogger that I want to make a proof of concept for in the future... This is just in my head for now... But here it it:

I often end up with bundles made by Webpack that are bigger than I'd like them to be. When trying to strip the bundle size down, I found one common cause of bloat that I've found very hard to address and that is logging frameworks. As in plural. As in 4 different logging frameworks in use by my one single application! Not as I intended this! The reason this happens is that there are many libraries out there that include a logger. Granted, most of them include debug, but loglevel is also very popular and there are others. And well, since I tend to pick ulog I often end up with 3 or 4 different logging libraries in my app.... :(

So here is the idea: What if we can pipe all logging done to debug, loglevel, log4js etc to anylogger? We could do this using a reverse adapter! Imagine these reverse adapters:

• debug-anylogger transforms debug logging to anylogger
• loglevel-anylogger transforms loglevel logging to anylogger
• log4js-anylogger transforms log4js logging to anylogger

We could then alias these logging libraries in e.g. Webpack, like this:

resolve: {
   alias: {
      "debug": "debug-anylogger",
      "loglevel": "loglevel-anylogger",
      "log4js": "log4js-anylogger",
   }
}

Webpack would then insert the adapters instead of the actual logging libraries. We would then install a regular anylogger adapter for the logger we end up choosing and instead of 4 logging libraries we get 1 logging library, 3 reverse adapters and one regular adapter. Ok so we will actually end up with more libraries in use, but the adapters tend to be waaaay smaller than the actual logging libraries so the end result should mean a significant reduction in code size. Oh and the joy of having all code in the app use the same logger, everywhere. That should make logging configuration much, much easier.

How difficult it will be to make these reverse adapters will depend on the complexity of the API of the logging framework the adapter is for and how well it maps on to anylogger. In fact, I am pretty sure that debug-anylogger won't even be needed and we could actually already do:

resolve: {
   alias: {
      "debug": "anylogger",
   }
}

because I made the API of anylogger so it's backwards compatible with debug. However, for loglevel and log4js it will be a bit harder. But hopefully not too hard!

So maybe you can see where I want this to end up. A simple mechanism to decouple javascript libraries from loggers so we can pick that only at the application level.

And as the author of ulog, I'd love for ulog to become the go-to logger to pick that is easy (because it's a native anylogger implementation) and that offers a feature set that can substitute for debug, loglevel and log4js.

Anyway, if one of you in enthousiastic enough about all this to want to join in development, please let me know and I will gladly make you a contributor.

Thanks for your support and patience!

-Stijn

[toddb]

Thanks for the message and I am glad you are back! Personally, using anylogger has been just what we needed except for the typescript support that has come through as pull requests. If you could get those into the packages, I can get back onto your packages.

Cheers

[Download]

Hi @toddb
Can you have a look at anylogger.d.ts
My problem is I have no experience with TypeScript.
But this file was contributed by a TypeScript user and it looks fine to me...
But I need someone with Typescript experience to check it / test it and help me fix the issues (if any)
If you make a PR against the current version of the anylogger codebase I promise I will merge it.
And if you feel it would be helpful I am willing to make you a contributor because we need more maintainers if we want this to be successful.

[toddb]

@Download there is also a pull request here for typings too. Can you get those in because I use the two together? Then I will update all my references in downstream projects that I have and look at the typescripts declarations. That sound okay?

As an aside, writing typings IMHO can be hard—so I don't. I write the code in typescript then the typings are free.

[toddb]

@Download Hey, I am just getting back to upgrading libraries and noticed that ulog is still not patched for typescript support which is a pull request in the message above. I need it for my own library!

I am really happy to help out as needed to get these patched and the typings correct—feel free to ping me.

[Download]

Hi @toddb,

I really value your input. So much so, that I'm willing to publish a new version of ulog just for you.

My issue

I am rewriting ulog. And yes, that's been taking way more time than I expected/hoped. And I keep getting interrupted with stupid things like work, family and friends etc... :D

Once ulog v2 is released, it will be just another adapter for anylogger. So for me, API wise, anylogger is leading.
Anylogger already is on v1.x and has a typings file. Can you please provide feedback on the anylogger typings file? Do you think it is ok as is?
Ulog v2 will be adding some extra methods and properties on the loggers created with anylogger:

• logger.levels (numeric property for the current level that corresponds with the level numbers in anylogger.levels)
• logger.assert(condition, message) mimics console.assert
• Maybe more...

What ulog v2 would need I guess is a typings file that somehow extends the one from anylogger.

however

The v2 beta version of ulog that is on NPM right now does not yet extend anylogger. So in the short term, we would have to create a typings file that does not extend the one from anylogger. Sorry for these complications but it will all go away once v2 is finally released.

My proposal

• Fork this repo
• Make a new branch in your fork based on v2.0.0-beta.7
• Implement your typings file.
• Make sure to update the typings declaration and version numbers in package.json
• Make sure all tests pass (locally, CI is broken again unfortunately)
• Create a PR

My promise

• I will pull your PR, test locally, merge and publish to NPM asap
• You get access to me personally for help/support during this PR
• You get full contributor rights to this repo as a reward once we published 2.0.0-beta.8

For the second point of my promise, I am willing to give you my phone number. Contact me over e-mail and I will give you my phone number and you will be able to contact me directly using What's App messenger.

stijn de witt @ gmail . com (no spaces)

[Download]

Done