The pino.destination() function is not defined on a browser (bug and/or documentation issue)

[zeel01]

This is related to or the same issue as #607, but I'm using Parcel rather than WebPack.

utils.js:25 Uncaught TypeError: (0 , _pinoDefault.default).destination is not a function

Issue #607 was closed and locked, but I don't feel like it was properly resolved. The issue here isn't really that destination doesn't work on a browser, it's understandable why that would be the case, it's that calling it throws an error and the fact that it isn't available isn't documented. The page linked from the other issue is https://getpino.io/#/docs/browser, which mentions the word "destination" only once but isn't talking about this method. The documentation for destination() at https://getpino.io/#/docs/api?id=pino-destination also don't mention that it isn't available in the browser.

The issue I ran into, is that I have some code that is shared between the backend and the frontend. In the browser this code doesn't need to do anything with the destination, it's just logging to the console, but the code that is setting up the backend logging is still in there. And when this code runs, that's a hard error and everything stops.

There are a few ways to work around this, I went with:

if (!pino.destination) pino.destination = () => undefined; // Fix for browser

I could have also just put an if (pino.destination) around the location it's being used, or I could use try/catch, etc. This is basically fine, albeit a little annoying. But I don't think it should behave this way without warning/documentation.

Suggested resolutions:

• Document which features and functions are completely unavailable for the browser on that page. Include advice for code that needs to run in either environment.
• Note that a feature or function isn't available in browser in its section of the API docs.
• And/or, provide a shim such as the one above that simply no-ops the function to avoid causing an error, or logs a warning so the developer is aware of the issue, or throws an explicit error with a clear message.

[mcollina]

Thanks for reporting! I think having a no-op would be problematic, but this certainly needs documenting. Would you like to open a PR?