Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eliminate high coupling to debug #3702

Closed
1 of 2 tasks
Download opened this issue Nov 23, 2020 · 5 comments
Closed
1 of 2 tasks

Eliminate high coupling to debug #3702

Download opened this issue Nov 23, 2020 · 5 comments

Comments

@Download
Copy link
Contributor

You want to:

  • report a bug
  • request a feature

Implementation

I'd be willing to create a PR for this feature.

Subject of the feature

Reduce coupling and footprint of minified file by using anylogger i.s.o debug

Problem

Currently, this library has a dependency on debug. Though that is an excellent library, this dependency has 2 major drawbacks:

  • This library is now forcing debug onto all developers that use this library (high coupling)
  • debug is 3.1kB minified and gzipped, directly adding 3.1kB to the minimum footprint of this library

Alternatives

Please have a look at anylogger. It's a logging facade specifically designed for libraries. It achieves these goals:

  • Decouple the library from the underlying logging framework
  • Reduce the minimal bundle footprint. Anylogger is only 370 bytes.

The decoupling is achieved by only including the minimal facade to allow client code to do logging and using adapters to back that facade with an actual logging framework. The reduced minimal footprint follows naturally from this decoupling as the bulk of the code lives in the adapter or logging library.

There are already adapters for some popular logging frameworks and more adapters can easily be created:

If this library were to switch to anylogger, you could still install debug as a dev-dependency and then require('anylogger-debug') in your tests to have your tests work exactly as they always did, with debug as the logging framework, while still decoupling it from debug for all clients.

Disclaimer: anylogger was written by me so I'm self-advertising here. However I do honestly believe it is the best solution in this situation and anylogger was written specifically to decrease coupling between libraries and logging frameworks because for any large application, devs typically end up with multiple loggers in their application because some libraries depend on debug, others on loglevel, yet others on log4js and so on. This hurts bundle size badly as we add multiple kB of logging libraries to it.

@darrachequesne
Copy link
Member

First, thanks for your efforts on this subject!

Are you referring to the browser bundle (socket.io-client), or do you think it should also apply to the server?

Note: the debug package is already stripped from the production build with webpack-remove-debug (here).

@Download
Copy link
Contributor Author

Hi @darrachequesne , thanks for taking this into consideration!

Basically I am referring to both the browser bundle and the server bundle.

Yeah stripping away debug in production builds is a great solution and you can do the same with anylogger of course.

But I like you to consider how great it would be for app developers if they could be the one to select the logging framework for their app and simply have socketio respect that choice. Not only in production but also (and maybe especially) during development.

Those developers that prefer debug would

npm install --save socket.io anylogger debug anylogger-debug

and in their entry point

require('anylogger-debug')

Those developers that instead prefer loglevel would simply

npm install --save socket.io anylogger loglevel anylogger-loglevel

and

require('anylogger-loglevel')

It is this flexibility, achieved by decoupling libraries from specific logging frameworks, that is anyloggers sole purpose.

@Download
Copy link
Contributor Author

I created some issues and PRs because I wanted to make a PR to change from debug to anylogger for you to check it out, but I first wanted to update the dependencies of this project but ran into some issues with that and got sidetracked. But maybe it's good. Now you can check some of my contributions and merge them if you feel they are useful and if this all goes well we can maybe discuss this issue after that.

@Download
Copy link
Contributor Author

Download commented Dec 5, 2020

@darrachequesne
I would love to prepare a PR for you to show you how I would decouple this project from debug, but when I set about to do that I noticed that I could not run the tests on Windows (see #3707 and #3708) and that many dependencies were out of date. So I thought let's fix that first and I started on that but it's now sorta in waiting state and I'm not clear on what... can you have a look at #3709 which describes exactly what I did to update all dependencies, lists a PR ready to be merged (I think) and 2 issues with Prettier and Mocha that prevent me from updating those but that also can probably easily be addressed.

@darrachequesne
Copy link
Member

I don't think that we will merge this.

Note: we could also move to Node.js built-in debuglog() if there is a real interest: https://nodejs.org/api/util.html#utildebuglogsection-callback

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants