deno
deno copied to clipboard
denoland
console.log({ a: string }) only prints 100 characters
Version: Deno 1.40.2
Logging an object only prints the first 100 characters of any strings in the object. This default needs to be higher. I see there is Deno.inspect but I'd rather not call console.log(Deno.inspect(value, { colors: true, strAbbreviateSize: 1000 })) every time I need to log to console. Node.js displays 10,000 characters. 1,000 would be better than 100.
console.log({ a: 'x'.repeat(150) });
{
a: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"... 50 more characters
}
console.log(Deno.inspect({ a: 'x'.repeat(150) }, { colors: true, strAbbreviateSize: 1000 }));
{
a: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
Guys... this is terrible. Only printing 100 characters of a string that you explicitly told the console to log is incomprehensibly bad.
I have a question.. does ANYONE here actually support the idea of only printing 100 characters with console.log ? Please speak up if you do. I'd love to hear your reasoning. Please explain to me why I only deserve to see 100 characters of a string I just told the console to log. PLEASE explain this to me. Thank You.
A max length is set to prevent large string output from being too overwhelming.
I agree, let's update maxStringLength to 10_000. Ref: https://github.com/nodejs/node/pull/32744
Here are screenshots of 1,000 and 10,000 characters. 1,000 takes up only a couple lines of terminal. 10,000 takes up a little bit more. At the very least I'd be happy with 1,000 which is about 10 times better than the current 100 characters! I'd probably take 10,000 too just to display all the information as default
1,000:
10,000:
100:
Guys... this is terrible. Only printing 100 characters of a string that you explicitly told the console to log is incomprehensibly bad.
I have a question.. does ANYONE here actually support the idea of only printing 100 characters with console.log ? Please speak up if you do. I'd love to hear your reasoning. Please explain to me why I only deserve to see 100 characters of a string I just told the console to log. PLEASE explain this to me. Thank You.
Since you asked, I do find the default behaviour very nice.
- for cases where I actually want full and complete strings in
console.log(obj)to be output, I have never even thought about not being explicit on the formatting, like whether it's pretty printed or not.
console.log(JSON.stringify(obj)) fits the bill nicely. If it's meant to be machine readable, I typically don't want pretty printing and have everything one line. And in the rare cases where nice human readable format with complete content is desireable, JSON.stringify can be easily configured to pretty print, or switched to something else (like Deno.inspect).
- when I specifically want to debug longer strings, just logging out the string property itself works as you'd expect and fits the bill nicely:
console.log(obj.a). In these cases, I don't typically want the JSON syntax around the text content I'm looking for - that would be hard to parse anyway, if the content has very long string properties.
Points (1) and (2) are to say that the current behaviour is easy to work around, and personally I never found the behaviour to be unexpected or even a surprise that logging objects may abbreviate textual content in properties.
- The main point in support of abbreviating log properties: Generally when just using
console.log(obj), it's for debug purposes, and by far most of the time I'm interested about the general shape of the object.
Does it have all the properties I expect it to have? Do the property values and their types seem sane? Abbreviating long string values and arrays help a lot in visually scanning the output for any unexpected shapes. When it comes to strings, I'm generally looking for numbers that are actually strings, empty strings that might be interpreted as falsy and so on.
Quite often I'm debugging objects in a loop to visually scan any outliers in the ouput, which further emphasizes the need for a conscise, easy to visually parse output format.
For point 3, the current behaviour feels very well thought out, and I like it. Thing is, console.log() with object parameters is "quick and dirty" and that's okay, especially because the abbreviation it currently does seems to have quite complex, well thought out logic, which if it didn't exist, feels like hard to accomplish in a more explicit manner.
I have a lot of different code running, 10 terminals on a 4k monitor, all of them logging various things, very often objects with strings, and EVERY SINGLE TIME I have an object with string that I NEED TO SEE I get the dreaded "x more characters" message and I wonder what exactly these people were thinking to only allow 100 characters in a string. These people must not work with console output or do anything serious
what exactly these people were thinking
These people must not work with console output or do anything serious
@e3dio You are violating our Code of Conduct:
- Please be kind and courteous. There’s no need to be mean or rude.
- Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.
- We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behavior.
@jtoppine provided meaningful answers to why "x more characters" is useful and logging full objects should use JSON.stringify.
That said, we will accept PRs that bump the current default limit to 10_000.
I also experienced this issue right now.
This is part of the object logged from a console.warn, and I found it both unexpected and strange that it cut off that early.
Luckily the search term "deno prevent console.log truncation" returned this issue as the second result!
I'd really like to see the maxStringLength increased, as I'd like to keep my logging utility both simple and portable.
@littledivy I'm not sure what happened with the PRs, but it seems the newest opened one is ready to go? If it isn't, please let me know - and I'll look into creating a PR myself :v:
Oh, and I think having somewhat parity with Node.js's console.log makes a lot of sense, good suggestion, Divy!
