console.json

[wmelton]

What is the problem this feature will solve?

Working with objects and arrays during node.js development can be a bit bothersome when needing to introspect a nested object, some REST-API response you're consuming, or intermediary DTOs, etc. I know I'm beating an old drum here, but when calling console.log(<object>) in hopes of seeing what we're working with, getting [object Object] in the console is less than helpful.

If you're lucky you may see the top level props, but are left with the lower level bits as still masked, e.g. { prop: { someChildPRop: [object Object] }}

While I'm sure there are age old reasons for all of this that are logical, from a developer experience and productivity perspective this is less than ideal.

What is the feature you are proposing to solve the problem?

An excellent alternative would be console.json(<JSON-serializable>) that essentially performs the same action that console.log(JSON.stringify(<serializable>, null, 2)) would perform. Perhaps pretty printing is an option flag, but regardless, having written this exact line of code 10k times in my life, console.json would be a breath of fresh air.

I'm happy to open a PR on this and do the leg work to make it happen if we can get buy-in to get it across the finish line. Feels like a low-risk feature that has a lot of developer productivity upside.

What alternatives have you considered?

I've considered continuing to write console.log(JSON.stringify(<JSON-serializable>, null, 2)) the rest of my life, and it makes me feel very sad inside.

[BridgeAR]

You can change the default inspection depth by setting util.inspect.defaultOptions.depth = 10. This might cause performance issues though.
I have a long outstanding plan on switching the default implementation from a depth first to a breath first algorithm but it's not easy to get this right as the code is quite complex dealing with inspection.

[wmelton]

Since JSON is a node native module, would it be totally disgusting for console.json to be an alias or wrapper for JSON.stringify() - maybe with some simple args to specify whether it should be pretty print style or just a flat string that gets printed to the console?

We could maybe coerce the eslint core team into making console.json a production build no-no, kind of like how console.log is these days anyway. Just thinking out loud on risk mitigation for performance hits in production from this.

I just keep thinking about the utility as a developer - would be so handy in 2023.

[BridgeAR]

Console methods adhere to a standard and thus, it's not possible to add that helper. And the overall goal would ideally be the solution mentioned above. That would as such also resolve your request, if I am not mistaken.

[Trott]

Console methods adhere to a standard

https://console.spec.whatwg.org/

[bnoordhuis]

This is basically a wontfix, right? I'll go ahead and close it as such.

[wmelton]

I wonder if these types of threads are why projects like Deno and Bun.sh are skyrocketing in popularity so quickly?

Standards are good and have their place, but when they become the default fallback that we blame for lack of innovation or shipping features that are just plain cool/useful, standards loose their luster rapidly.

Guess Node.js maintainers aren't really interested in building/shipping product features that average developers would love and be excited about even if they draw outside the lines of "standards" occasionally? Sad.

[cjihrig]

@wmelton have you considered opening an issue at https://github.com/whatwg/console/issues?

FWIW, I agree with some of what you've said, and disagree with other parts.

[wmelton]

@cjihrig I haven't. Feels like starting at the top of a long bureaucratic chain to get a really cool/useful feature shipped is the wrong path for projects that want to stay competitive/relevant.

Anyway - not gonna keep wasting your alls time. Thanks for entertaining my offer to commit a cool feature. Sorry to hear the decision making processes are structured to overly value what they do.

I love JavaScript/TypeScript deeply. Hope more long-term, competitive decision making starts being had amongst the node.js crew. I don't imagine many people will feel a lot of loyalty lost to start typing deno ... or bun ... instead of node ... if those projects are willing to work outside of standards for the sake of delivering features people just love using.

[bnoordhuis]

@wmelton it's that Colin already replied to you, otherwise I'd have hidden your comments as off-topic rants. Save it for twitter, it's not welcome here.

[wmelton]

@cjihrig for what its worth, I did open a thread over at whatwg but as I suspected, likely a long battle convincing folks of what seems obviously hugely helpful and different than what's available: whatwg/console#222

@bnoordhuis criticism and rants are very different. Only those with mindsets oriented towards success can be bothered to receive the first without unhelpfully categorizing them as the latter.

[paulirish]

You can change the default inspection depth by setting util.inspect.defaultOptions.depth = 10. This might cause performance issues though.

@wmelton why doesn't this work for you? This seems like the solution for your problem. I use this trick often myself.

IMO this solution is favorable, too, as the syntax highlighting of objects is more distinctive than that of JSON.

[wmelton]

@paulirish reasonable question. I think some of my examples given in the whatwg issue I opened help drive at why, but to recap:

• It's not universal. If I clone a project and want to inspect some value generated by it, if I call console.log() on the object, unless I've gotten the util.inspect.defaultOptions.depth = 10 config declared at the top of the project, its not going to help me. Seems like a frustrating developer experience path to have to remember to go add that to any myriad of projects I just cloned.

• As I mentioned in the discussion over at whatwg, this still requires that the objects I'm working with (of which I may have never seen before) to in fact have all the important parts within 10 child nodes of the parent. If it doesn't, I'm back to either logging json.stringify again, or updating defaultOptions.depth with a new depth until I find the right one, which is frustrating from a developer productivity perspective.

• Performance issues seem like a secondary concern. If someone committed console.json on a production commit for a really big object.... I feel like that's on the developer to do better lol. I work with XML feeds in the real estate industry that regularly have the biggest, gnarliest, super deep object structures (once parsed to json) you can imagine. I routinely have to console print the entire object to get a fundamental understanding of what all is in the object. I usually do this with console.log(JSON.stringify(object, null, 2)) - performance of waiting for that log to print on my local machine is never a consideration or concern for me, even with massive objects. For me its about speed and utility when trying to develop and debug.

• As mentioned on the whatwg thread, the depth flag in the util.inspect option is ultimately an expander in the sense that normally it is very limited, but you are asking it to relax. Whereas if we implemented console.json in the whatwg standard, I would advocate that any optional depth flag would be a limiter, allowing console.json to unfurl the object completely by default, and allow users to pass the depth flag to limit the expansion to only that depth (if performance considerations were a concern, for example). Developers still have control in this way, but the depth control is inverted.

• console.json would feel undoubtedly intuitive under the fingers of a developer. This is of course an opinion, but it seems like we've seen an explosion in frameworks in multiple languages adding their own .toJSON() functions/methods because it is so common for developers to want to see an object expressed as JSON (and shipped around in API requests, etc)

If I came across as a jerk earlier in this thread, I apologize. Very passionate developer and avid js/node fan. It was admittedly frustrating to feel like my proposal was discarded so quickly without a lot of thought or discussion.

I think this would be a dope feature to roll out. Not sure whatwg is going to add this to their standard though, so not sure where this all leaves us since whatwg is looping us back here.

Thanks again for hearing me out.

[wmelton]

Bumping this thread in case there's any interest in pursuing this any further.

[wmelton]

@paulirish how do you handle that config universally across all repositories/projects? How do you handle dealing with other companies gnarly nested objects? Genuinely seeking to understand.