VS Code: intersection types, type not assignable

[sKopheK]

Hello, using VS Code to have typed JS (checkJs: true), but it seems to be having troubles with intersection types that work in both TS and JS in TS Playground without any error. Interestingly enough, properties from a second intersected type are correctly detected by VS Code despite the error on assignment of the typed value (see intellisence tooltip on the screenshot in Actual behavior).

TypeScript Version: 3.9.0-dev.20200420

Search Terms:
not assignable, Intersection types

Code

const ExtraProps = {
    one: 1,
    two: 2
}

class Test { }

/** @type {Test & ExtraProps} */
const inst = new Test();
inst.one;    // no complains

Playground Link

Assigning a properly defined type also does not work:

/**
 * @typedef {{[x in "one"|"two"]: number}} ExtraPropsType
 */

/** @type {Test & ExtraPropsType} */
const inst = new Test();

Expected behavior:

Actual behavior:

[RyanCavanaugh]

The behavior in VS Code is the desired one. Something's wrong with the Playground

[sKopheK]

The behavior in VS Code is the desired one. Something's wrong with the Playground

is both error for value assignment and later proper property detection desired tho?

regarding the playground: does the same problem occur in the following TypeScript code?

Playground Link

[IllusionMH]

Just in case - there are no errors reported for JavaScript in current playground (see microsoft/TypeScript-Website#203) so unfortunately you can't rely on it.

But you can see same error in Errors tab of new playground

[sKopheK]

wasn't aware of the new playground, thanks.
seems like a bug then, but I'm wondering, how should this TS code behave then. no errors even in the Errors tab, correct recognition of properties from the second intersected type:

Playground Link

If the TS behavior is correct, how to write JSDocs in JS files to have the same functionality available?

[IllusionMH]

This one is type assertion which is completely different and might be not safe.

Type assertions are a way to tell the compiler “trust me, I know what I’m doing.”

This is definitely not the same as JS which correctly reports type that has missing properties.

Anyway you can use parenthesis

/** @type {Test & ExtraPropsType} */
const inst = (new Test());

Which won't allow to check types in JS and won't complain. But it's still unsafe (as with most JS checks) so use it with care.

[sKopheK]

Thanks. Everyday, I'm learning so many new things about TS :).
I might have wrong thinking with all this overly complex structures and a bit too generic approaches, but I like to follow DRY principle and as TS does not support #38115, I have to use some workarounds to have my code realm by my desires.

[orta]

Linking this to microsoft/TypeScript-Website#203 - I'm aiming to get this in before the 3.9 release build of the playground

[orta]

The JS support for errors should be fixed on the staging site as of tomorrow: https://www.staging-typescript.org/play

[orta]

The Playground and VS Code provide the same errors the same here when in JS mode on nightlies:

@IllusionMH is right, the underlaying misconception here is what the @type is being applied to:

/** @type {Test & ExtraPropsType} */
const inst = new Test();

is like const inst: Test & ExtraPropsType = new Test(); vs

/** @type {Test & ExtraPropsType} */
const inst = (new Test());

is like const inst = new Test() as Test & ExtraPropsType

Which is why we get the error without the braces. This leaves the question to me as: Should we consider this a bug and always assume the as condition in this space?