Well I suggest to not include Winston at all. Winston is kinda huge and contains a lot of nice features that your users might not use, and I believe that your module should be small enough that the user will always use all it's features. If there's a case that they don't wanna use the built-in logger, well it's not small enough I guess. With that said, a module logging stuff when needed for debugging is helpful.
If you wanna have way for the developer using your module to debug your module with logs, then I suggest you to have a debug mode that can be turned on/off.
You could use something like this to help you: https://www.npmjs.org/package/debug
And if the user wants to integrate their own logging system, I suggest you to have a way that they could pass your module a logging function. Something like this(let's call your module rock-the-sock:
var rockTheSock = require('rock-the-sock');
var rockTheSock.logger = function (level, message, metadata) {
console.log('level :', level, message, metadata); // TODO: Integrate winston
};
rockTheSock.startRocking();
And then in your module you would have a default logger, which can overriden as shown above.
socket.io is a nice example of how it's done(though you don't really need the configure method, that's just bells and whistles):
Here's how you would override socket.io default logger: https://github.com/LearnBoost/Socket.IO/wiki/Configuring-Socket.IO
Where as the logger is implemented this way: https://github.com/LearnBoost/Socket.IO/blob/0.9.14/lib/logger.js
And if ever something goes wrong, try to throw the error, or emit an 'error' event or call the callback with the error(do whichever applicable). Silently logging it, is not a good idea. If you are reporting it, then let the user code handle it. Maybe the error was expected(you have no idea in what crazy ways people use your modules!).