JS `print` function adds unexpected output

[gibson042]

Summary

When I print a string with the ladybird-js executable, it wraps the output in quotes, and when I print an array, it adds brackets and whitespace. This differs from the CLI output of other implementations, causing noise when checking behavior with eshost.

Operating system

Linux

Steps to reproduce

1. Inside a suitable environment (e.g., docker run --rm -it ubuntu:noble bash),
2. Install Node.js, npm, esvu, eshost{,-cli}, and JS implementations including ladybird-js: 1. apt-get update && apt-get install -y curl glibc-source zip 2. curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.2/install.sh | bash 3. . "$HOME/.nvm/nvm.sh" 4. nvm install 22 5. npm install -g esvu eshost eshost-cli 6. sed -i "/this[.]registerAssets[(]'lib[/][*][*]'[)]/d" "$(dirname "$NVM_BIN")/lib/node_modules/esvu/src/engines/libjs.js" # fix esvu for the current ladybird artifact shape 7. for engine in JavaScriptCore LibJS SpiderMonkey V8 XS; do esvu install $engine; done
3. Configure eshost to use them: 1. eshost --configure-esvu && eshost --add Ladybird serenity-js ~/.esvu/bin/ladybird-js && eshost --list
4. eshost -se '(() => { print("print directly", ["blue", 42]); return "eval-and-print"; })()'

Expected behavior

Ladybird produces output matching the other implementations:

#### JavaScriptCore, Ladybird, Moddable XS, SpiderMonkey, V8
print directly blue,42
eval-and-print

Actual behavior

Ladybird adds quotes, brackets, and whitespace:

#### JavaScriptCore, Moddable XS, SpiderMonkey, V8
print directly blue,42
eval-and-print

#### Ladybird
"print directly" [ "blue", 42 ]
"eval-and-print"

The array detail is actually fine (and the analogous object properties detail like Object{ "foo": "bar" } is great!), but printing of string arguments should really conform with the other implementations.

URL for a reduced test case

N/A

HTML/SVG/etc. source for a reduced test case

N/A

Log output and (if possible) backtrace

N/A

Screenshots or screen recordings

No response

Build flags or config settings

No response

Contribute a patch?

• [ ] I’ll contribute a patch for this myself.

[ADKaster]

This discrepancy was previously discussed in #3998 and https://github.com/LadybirdBrowser/ladybird/issues/3998#issuecomment-2736495122

Are these the only obvious print difference between our REPL and those of other engines? iirc our printing of deeply nested and self-referential records gives it a try and then gives up after a certain number of visited nodes, often printing "<already visted object 0xaaaaaa>" far earlier than expected.

Perhaps we could add a "raw print" function to the REPL? Or a command line flag to disable the 'pretty/formatted' printing we're intentionally doing here?

Another avenue, is this sort of print behavior something that could be defined by TC55?

[gibson042]

Are these the only obvious print difference between our REPL and those of other engines? iirc our printing of deeply nested and self-referential records gives it a try and then gives up after a certain number of visited nodes, often printing "<already visted object 0xaaaaaa>" far earlier than expected.

They're not the only differences, as I observed under "Actual behavior" above («the analogous object properties detail like Object{ "foo": "bar" } is great!»).

Perhaps we could add a "raw print" function to the REPL? Or a command line flag to disable the 'pretty/formatted' printing we're intentionally doing here?

My suggestion would be to print top-level strings without quotes (such that e.g. print("foo") prints foo and print("foo", "bar") prints foo bar), but feel free to leave everything else unchanged. Failing that, though, a command line option would also work. The real need here for me is that eshost can run Ladybird JS in such a way that print(string) produces output that behaves like other implementations.

Another avenue, is this sort of print behavior something that could be defined by TC55?

Yes, quite possibly.

[linusg]

Another avenue, is this sort of print behavior something that could be defined by TC55?

I don't see why that would be necessary - console is already sufficiently standardized and part of TC55's https://min-common-api.proposal.wintertc.org. The solution is not to have a second print function, it's for engine shells to implement already standardized functionality instead of making up their own if interop is a concern.