I'd like to see the entire error message.
In tsc.js
:
function typeToString(type, enclosingDeclaration, flags) {
var writer = ts.getSingleLineStringWriter();
getSymbolDisplayBuilder().buildTypeDisplay(type, writer, enclosingDeclaration, flags);
var result = writer.string();
ts.releaseStringWriter(writer);
var maxLength = compilerOptions.noErrorTruncation || flags & 4 ? undefined : 100;
if (maxLength && result.length >= maxLength) {
result = result.substr(0, maxLength - "...".length) + "...";
}
return result;
}
But adding in tsconfig.json
:
{
"compilerOptions": {
"noErrorTruncation": true
}
}
has no effect.
It seems that there's no other mention of that noErrorTruncation
in the file -- I assume it's simply undefined (and I could also find no documentation about it).
Adding to ts.optionDeclarations
this entry:
{
name: "noErrorTruncation",
type: "boolean"
},
makes it work.
noErrorTrunction was meant for the API users calling directly into the API with CompilerOptions object, e.g. IDE's, and not from the commandline.
The asumption is on the commandline no one wants to see the full error, as serlized types can be huge.
So can you elaborate on why this is needed? and would you use this all the time? do you use --pretty
as well?
@mhegazy I definitely want to see the full error. The types I'm using (provided by others, so I cannot change them easily) are very long, and typically contain the ... & type & type
unions I care about at the end. It's OK if the errors are shortened by default, but when trying to solve type errors like in my case, it can be really hard if you can only see the first 100 chars of a 200 char type.
A PR to add the compiler option would be appreciated.
so do you use an IDE? would getting the errors there be a better option?
@nh2 can you clarify how you worked around this? I have a similar error that I want to see the full error for.
Oh, it looks like adding this to tsconfig.json
works now
{
"compilerOptions": {
"noErrorTruncation": true
}
}
I think this issue can be closed.
@nicksnyder I confirm that the compiler option you mentioned is working for me too. I can't speak for @nh2 but IMO this issue is fixed in the compiler.
OK great, let's close this then -- we can reopen it if we find that something doesn't work yet.
Most helpful comment
Oh, it looks like adding this to
tsconfig.json
works nowI think this issue can be closed.