feat: add util.inspect with full options support

[chessbyte]

Issue # (if available)

Fixes #1257

Description of changes

Implements util.inspect() function with the following features:

• depth: control recursion depth for nested objects (supports null for infinite)
• colors: ANSI color output support
• showHidden: show non-enumerable properties
• customInspect: call Symbol.for('nodejs.util.inspect.custom') methods
• maxArrayLength: limit array/set/map elements displayed
• maxStringLength: truncate long strings
• sorted: sort object keys (boolean or custom comparator function)
• breakLength: line length at which to break to multiple lines
• compact: control inline vs multiline formatting (number or false)

Also exports:

• util.inspect.custom symbol (nodejs.util.inspect.custom)
• util.inspect.defaultOptions object

Checklist

• Created unit tests in tests/unit and/or in Rust for my feature if needed
• Ran make fix to format JS and apply Clippy auto fixes
• Made sure my code didn't add any additional warnings: make check
• Added relevant type info in types/ directory
• Updated documentation if needed (API.md/README.md/Other)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[Sytten]

I have a vague memory that console.log is a limited version of inspect but that they share codebase (I might be wrong on that). Could there be some re-use?

[richarddavison]

I have a vague memory that console.log is a limited version of inspect but that they share codebase (I might be wrong on that). Could there be some re-use?

Yes they do and we should do so here I as well.

@chessbyte when I created console initially I build it a bit simplified and "just" appended the string recursively.

In order to conform more to Node.js and other runtime we should do a two phase approach instead. So instead of building the string from the get-go in a single pass we can store the console line in an internal representation enum of the actual values. Then we can render them to stdout/stderr using a renderer which actually prints the message. This way we can adjust when to line break depending on how many items that are in the object/array/string etc and format depending on terminal width etc. This is exactly how it's done in Node where printing e deeply nested object on a small window renders different output and "pretty-print" vs doing so on a larger screen. The performance impact of this should be quite small since we're not going to deep anyway and is still appending to a string buffer first before printing.

So in summery:
Build print PrintIR from JsObjects
Then use a renderer to output it that deals with newlines, indentation, expansion, collapsing, truncating etc

@Sytten thoughts?

[chessbyte]

@richarddavison @Sytten hoping I addressed feedback in 2nd commit

[Sytten]

Agreed this is the way to go

[chessbyte]

@Sytten @richarddavison what is the status of this PR? It has been sitting since my changes on Saturday without any activity.

[Sytten]

No offense but we cant just merge 2k lines of vibe code just like that. We work on llrt when we can and we will need to maintain that code for the years to come, this will take a least a couple weeks to get merged.

[chessbyte]

When I ran the open-source project ManageIQ for a decade and received PRs, I treated them as serendipitous gifts. When I felt they were too complex, I would request that they be chopped into multiple smaller PRs. When I felt that the code may be unstable, I would ask for more tests. When I did not like the code organization, I would suggest something more suitable to the project. That project is still going strong at manageiq.org :-)

Your feedback is a bit insulting to someone who is genuinely trying to help move along a project that achieved NONE of its targeted goals for 2025.

Perfect is the enemy of good enough! Best of luck with your approach!

[richarddavison]

When I ran the open-source project ManageIQ for a decade and received PRs, I treated them as serendipitous gifts. When I felt they were too complex, I would request that they be chopped into multiple smaller PRs. When I felt that the code may be unstable, I would ask for more tests. When I did not like the code organization, I would suggest something more suitable to the project. That project is still going strong at manageiq.org :-)

Your feedback is a bit insulting to someone who is genuinely trying to help move along a project that achieved NONE of its targeted goals for 2025.

Some things takes a while to get right. We prioritize to get them right then to ship to soon. Most of these features have a lot of edge cases that needs to be handled.

Perfect is the enemy of good enough! Best of luck with your approach!

We do highly appreciate all PR and effort to make this project better and add more features. Thanks for the work you have done. However, significant changes like this will take a while to get through. I also see a couple of optimization paths we can do with this. Thanks for contributing and I encourage you to continue to do so!

[chessbyte]

Some things takes a while to get right. We prioritize to get them right then to ship to soon. Most of these features have a lot of edge cases that needs to be handled.

@richarddavison I would like nothing more than to add as many tests as there are edge conditions, so that we all feel comfortable about the implemented code.

We do highly appreciate all PR and effort to make this project better and add more features. Thanks for the work you have done. However, significant changes like this will take a while to get through. I also see a couple of optimization paths we can do with this. Thanks for contributing and I encourage you to continue to do so!

@richarddavison I have no issue with PRs taking time to merge because you want to get big changes right. Having said that, before this project reaches 1.0 status, I encourage you to iterate quicker and trust your tests to avoid regressions.

This particular PR introduces new functionality to address a reported issue of missing functionality. It should not break any existing users of llrt as nothing should be using util.inspect, and, therefore, requires a bit less scrutiny, IMHO. Regardless, I defer to you as the project maintainer.