TS7018 error without file and line number

[ktrz]

🔎 Search Terms

filename, noImplicitAny, TS7018, 7018

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about TS7018, line number, filename

⏯ Playground Link

https://www.typescriptlang.org/play?strict=false&strictNullChecks=false&jsx=0&ssl=9&ssc=14&pln=8&pc=7#code/GYVwdgxgLglg9mABAEzgZSgCwOoywBQEMAnQgWwGcAKABxPIoC5FwBrMOAdzAEpEBvAFCJEMYIipQAnjQCmccXVKVEAQgC86xAHI4AIwBWs6Nr5CRI4rKghiSfgF8A3MMQPBrqzbsDXIiMzawHBw2gA0fog0gXok4ZFMOrEAXvEizoLughAIFFCIscSIWuZRzGAgADaVESKJFdW1iAB0ragYOHiYRMrUpSLROpiy1aFNdYGccMSVyGluPBEZQA

💻 Code

function doSthWithParams(params: unknown) {
  if (typeof params !== 'object') {
    return {};
  }

  return {
    c: 'foo',
    p: 'bar',
    s: 'baz',
  };
}

const bar = {
  p: null,
  s: null,
  ...doSthWithParams({
    p: 'hello',
    s: 'world',
  }),
};

🙁 Actual behavior

We're trying to incrementally get our codebase toward the strict mode. When we've enabled noImplicitAny flag we got an error that was very hard to track as it didn't give a file and line number where the error happens.

Object literal's property 'p' implicitly has an 'any' type.

Object literal's property 's' implicitly has an 'any' type.

🙂 Expected behavior

The TS compiler error should point to a file and line number where the error occurs

Additional information about the issue

This happens if noImplicitAny is true and strictNullChecks is not yet enabled

[fatcerberus]

This just looks like a bug - there shouldn't be an error in this code at all.

[Andarist]

This just looks like a bug - there shouldn't be an error in this code at all.

What would be the correct behavior here? We get no implicit any error here outside of strictNullChecks (which this issue is about):

const obj = {
  prop: null, // Object literal's property 'prop' implicitly has an 'any' type.(7018)
};

In the OP's example the computed type of bar is:

const bar: {
    c?: undefined;
    p: any;
    s: any;
} | {
    c: string;
    p: string;
    s: string;
}

I guess that p and s in the first member could somehow inherit here a string type. It would require special-casing this here and investing time in a strictNullChecks: false cases is not something I'm that interested in doing myself :P Is it even worth it at this point? Fixing error positions here seems like a reasonable solution to me.

[fatcerberus]

What would be the correct behavior here?

To be 100% clear, the behavior I'm calling a bug is there appears to be an error on the object literal returned by the function doSthWithParams; bar seems to not be an error. If either one of the returns in that function is removed, the error in question goes away, which just feels like the kind of spooky action at a distance Ryan always harps against.

[fatcerberus]

Anyway, if the reported behavior isn't a bug, this surely is:

function doSthWithParams(params: unknown) {
  return {
    c: 'foo',
    p: 'bar',
    s: 'baz',
  };
}

const bar = {
  p: null,
  s: null,
  ...doSthWithParams({
    p: 'hello',
    s: 'world',
  }),
};

Variable 'bar' implicitly has an '{ c: string; p: string; s: string; }' type.

Umm... wut (also note that this error names the variable bar, while the error in the OP doesn't)

[fatcerberus]

Even more janky fun:

1. Comment out return {} in the playground from the OP
2. Observe that bar now becomes an error (the same as the one demonstrated above)
3. Uncomment the return
4. All errors are now gone!

[Andarist]

I also noticed the above and I think it's fixed with my PR. I don't think it's worth looking more into it - the problem was that the error was reported on an undefined node and that should never happen. When that happens (node === undefined) a compiler-level diagnostic gets created (with file: undefined on it). I think that getDiagnosticsWorker might accidentally be dropping them here but that it only affects a situation that shouldn't exist in the first place.