Most libraries, log their version number (and some other data) when you import them. Sometimes, you can disable this behavior, sometimes you can't.
I don't find it awfully bothering, but I wonder what everyone think about it.
Most libraries, log their version number (and some other data) when you import them. Sometimes, you can disable this behavior, sometimes you can't.
I don't find it awfully bothering, but I wonder what everyone think about it.
For further actions, you may consider blocking this person and/or reporting abuse
Mohammadali Rezaei -
Erick Okal -
Daniel Azevedo -
Vergel Eeee -
Top comments (17)
Libraries doing any kind of logging is a horrible thing.
Results in polluted logs and all sorts of problems that are easily prevented by just allowing developers to either pass in a logger of their choice or return back data when calling whatever things it exposes and then letting me decide what to log.
Similar with libraries outside js world too, personally I would extend this thought process to all I/O unless that's the purpose of the library.
I agree with the polluted logs argument. But I can see some pros to log too. I like the passed logger tho
I don't see the added value in that :D It doesn't seem to help neither the developer nor the user. Anyway if I had to do it I would use
console.debug
instead ofconsole.log
...IMO, it could help users to fill issues and help devs with discoverability.
In theory but normal users don't know about the web developer tools (why should they?) and it doesn't help mobile users anyway...
Also, if the library is shipped to all users, all users likely have the same version.
By users I meant the ones using the lib so webdevs.
Yeah but I already know which version it is, I installed it 😬 anyway it doesn't do any harm so well, let's leave it at that ✌🏾
Agreed. I think they should be logged.
Some of principles that good library should match is single responsibility and minimally surprising behavior. Library shouldn't do things that isn't expected from it and do exactly what it is aimed for. But good library should have ability to provide its' version. Especially for shared library...
And good practices for programmer is to provide this info in log for guys who will support your application. It helps to fix issues very very much.
Yeah... As people said, programmer usually knows libraries' versions. But guys who will you support it, may not know. Environment may contains several versions of the same library installed. And application may take version that not supposed initially. And it's pretty typical issue.
Of course, If you write an app just for yourself it's totally up to you...
My first thought was for discoverability. Some devs see something cool on the web, open the console and see
Build with love using "MyAwesomeApp v1.0.0"
.Thanks, to others comments, I realize that if every lib do the same, log can be cluttered.
Imagine:
However, I agree with you on:
It's funny. But you even cannot imagine how similar message really helps to discover issues. Especially If it's critical application...
Do you have an example ?
Yeah, this seems obnoxious. If this were part of a well-documented config which also let you make other adjustments and was easy to toggle, I'd be cool with it.
But that doesn't seem like what you're describing, so I agree.
Having mostly worked with Node for years, where there's only one log stream, there have definitely been times I've missed log4j. Init messages showing up at trace level but not below is exactly how it should be.
For the records, I decide to not log anything in the console. I just made some useful informations available at the namespace root (version, author and homepage) read directly from package.json.
ESLint to the rescue?