Enable Typescript to understand JSX default props

[Alexendoo]

This addition allows a Component to use defaultProps without having to declare them as optional, in a nutshell:

Before

class Before extends Component<{ prop?: string }> {
	static defaultProps = {
		prop: "default value"
	};

	render() {
		// this.props.prop is string|undefined
	}
}

const element = <Before />;

After

class After extends Component<{ prop: string }> {
	static defaultProps = {
		prop: "default value"
	};

	render() {
		// typeof this.props.prop is string
	}
}

const element = <After />;

The definition isn't perfect, it doesn't quite understand type unions where the type of a single property changes, e.g.

{ type: "number"; value: number } | { type: "string"; value: string }

But this case doesn't break, it just would require you to still provide a property.

There might be some more things we can do with LibraryManagedAttributes, it could allow the children property to be correct within Components (always an Array) whilst still allowing components to specify the type of children they accept.

[coveralls]

Coverage remained the same at 100.0% when pulling d1974c7 on Alexendoo:typed-defaultProps into 62c04e0 on developit:master.

[developit]

Ahhh yes, I totally wished for this yesterday! Good timing, thanks @Alexendoo :)

[developit]

I'm guessing this requires TS 3+? Might be worth putting this into 9.0 if so.

[Alexendoo]

Yep the feature requires 3.0 to receive the benefits of it, on 2.8/2.9 it provides no improvements, for them it is just an extra type on JSX that it doesn't use so nothing changes.

However it is a breaking change, it requires TS >= 2.8 because of the conditional types, even if they aren't used they are still present in the declaration file. I don't know what the minimum version of
typescript preact currently requires but I expect it to be below 2.8, I would guess 2.3 (generic defaults) from looking at the file.

[developit]

@marvinhagemeister might know what we currently require. For some reason I feel like I remember adding a 2.8-specific feature?

[marvinhagemeister]

@developit I thought too that we had something specifically added with TS 2.8 but looking at the types again we don't have added any breaking change yet. The one with type checking children is simply ignored on older TS version because it's just an interface.

With this PR we need to update our TS version requirements to at least 2.8 and better 3.0. I'm totally fine with this as I upgraded multiple major code bases to 3.0 without any issues at all.

The CI failure seems strange. Looks like npm install doesn't finish correctly.

[marvinhagemeister]

LGTM, thanks for another great PR 🎉

[developit]

CI had only failed on one of the node versions, which means it's a fluke.

Should we wait a bit before jumping to TS 3.0? It only came out 2 weeks ago right?

[Alexendoo]

I think it should be fine since it won't break on 2.8 and 2.9

Plus the 3.0 release isn't as scary as it sounds, I think 2.9 -> 3.0 is just how they wanted to do version numbering, TS doesn't use semver since most releases are breaking changes in a type system. It actually has pretty few breaking changes so it should be an easy update for most

[marvinhagemeister]

Would love to merge this, but the CI is giving me trouble. Not sure why node8 fails to install the proper dependencies.

[Alexendoo]

node_modules is set to be cached, maybe it's an issue with the cache it's pulling in each time?

[Alexendoo]

Could be worth giving this a shot @marvinhagemeister https://docs.travis-ci.com/user/caching/#clearing-caches

[marvinhagemeister]

@Alexendoo You're right, that fixes it 🎉