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.
Guillaume Martigny @gmartigny
About: JavaScript spitter and video-games gatherer.
Location:
France
Joined:
Feb 25, 2018
Should a library log its version number ?
Publish Date: Aug 20 '18
13 17Comments 17 total
Guillaume MartignyAug 20, 2018IMO, it could help users to fill issues and help devs with discoverability.
- rhymesAug 20, 2018
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.
- rhymesAug 20, 2018
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 ✌🏾
Chris JamesAug 20, 2018Libraries 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.
- Guillaume MartignyAug 20, 2018
I agree with the polluted logs argument. But I can see some pros to log too. I like the passed logger tho
Ben HalpernAug 21, 2018Yeah, 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.
Dian FayAug 21, 2018Having 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.
- Guillaume MartignyAug 21, 2018
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.
northbearAug 21, 2018Some 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...- Guillaume MartignyAug 21, 2018
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:Use JQuery 3.11 Build with Bootstrap@4 Made with love with Webpack v4 Propulsed by _Underscore_ Careful Google Analytics is watching you ...However, I agree with you on:
good library should have ability to provide its' version.
- northbearAug 21, 2018
It's funny. But you even cannot imagine how similar message really helps to discover issues. Especially If it's critical application...
G.Sep 6, 2018ESLint to the rescue?
"no-console": [2, { "allow": ["info", "warn", "error", "exception"] }]
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.debuginstead ofconsole.log...