Default param causes ts-check to fail

ts-check-bug-simpler.js

const Obj = {
    x: 1,
    f: (y = Obj.x) => {}
};

Obj.x; // No definition found for 'x'

Really strange: using anything other than same const works well, but using same const as host object breaks intellisense:

// @ts-check

const o0 = {p:0}
const o1 = {p:1,m:(a=o2.p)=>a}; // default param uses next const prop
const o2 = {p:2,m:(a=o2.p)=>a}; // default param uses SAME const prop
const o3 = {p:2,m:(a=o0.p)=>a}; // default param uses first const prop

o1; // intellisense works: {p: number; m: (a?: any) => any; }
o2; // intellisense borked: any
o3; // intellisense works: {p: number; m: (a?: number) => number; }

Ah, if you run it through full TypeScript you get this error on Obj:

'Obj' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer.

So x is any because Obj has to be any. I guess this is the disadvantage of using JS + JSDoc-style usage of the TS type checker - some errors will be hidden.

Used this TypeScript code to reproduce it.

Ah, great find! And it is neatly visible how it works when using "other" objects in default params and what's wrong with const x = { prop: x } (what yields error in JS anyway).

I wonder if VSC could report such problems in panel; tried enabling TS Server log but couldn't find anything helpful there.

(Anyway, in my setup I rarely hit such problem: I stick to really "dumb" JS for ancient browsers, so no consts, no default params, but still enjoying type checking from JSDoc definitions.)

Cool, yeah. I definitely prefer this JSDoc approach in general for "lightweight" type-checking on small projects / prototypes without setting up a full TypeScript tool chain.

Exactly.
And amusingly, just accidentally caught this approach in that very editor:
https://www.typescriptlang.org/play/main-3.js

// whoa, no typescript and no compilation!

😄

(Sorry for spam, just had to share. Happy holidays :] )

OH, and BTW, if you are using modern-ish JS, you'll probably need do add few libs to "have" some features missing in current TS standard defs; for example in service worker I needed

/// <reference lib="webworker" />
// `Property 'finally' does not exist on type 'Promise<void>'`, introduced with es2018
/// <reference lib="es2018.promise" />

Hah, nice! Happy holidays!