Default value of an object pattern property should not change type if it's assignable

[kdy1]

stc/crates/stc_ts_type_checker/tests/conformance/types/nonPrimitive/nonPrimitiveAndEmptyObject.ts

Lines 6 to 17 in d121f20

	export interface BarProps {
	barProp?: string;
	}
	export interface FooProps {
	fooProps?: BarProps & object;
	}
	declare const foo: FooProps;
	const { fooProps = {} } = foo;
	fooProps.barProp;

This should success.

access_property of ((BarProps#1 & object) | {}) is expected to fail, because {} does not have the property.
But the type of fooProps should be (BarProps#1 & object) (without union)

I think the logic at

stc/crates/stc_ts_file_analyzer/src/analyzer/scope/vars.rs

Lines 483 to 500 in d121f20

	if prop.value.is_some() {
	prop_ty = prop_ty.map(|ty| {
	// Optional
	ty.map(|ty| {
	Type::new_union(
	span,
	vec![
	ty,
	Type::Keyword(KeywordType {
	span,
	kind: TsKeywordTypeKind::TsUndefinedKeyword,
	metadata: Default::default(),
	}),
	],
	)
	})
	});
	}

is problematic, and I think we should adjust it to ignore default value if the type of the default value is assignable to the original type.

[kharvd]

Hi @kdy1, I'd like to give it a try!

[kdy1]

Thanks!

[kharvd]

Is the object part relevant here? Looks like tsc infers BarProps even when fooProps has type BarProps, without the object intersection.

I would guess we should infer BarProps | DefaultValue if DefaultValue is not assignable to BarProps & object, and just BarProps otherwise. {} is assignable to BarProps & object (or BarProps fwiw), so we should infer BarProps & object

[kdy1]

I think you are right, nice catch! Thank you.

I tried incompatible default value and it matches with your observation