Poor IDE errors on some types

[joeduffy]

I was trying to write a blog post to demonstrate some of the benefits of having real code in an IDE: namely, interactive error messages for typos, type errors, and so on. Unfortunately, the first several times I tried, the error messages were in fact not very good. I am using our Kubernetes template project from https://github.com/pulumi/templates/tree/master/kubernetes-typescript, and I've filed this issue here because I suspect the problem might be in the way we've laid out our Kubernetes types.

I am assigning to @CyrusNajmabadi for now because he graciously offered to help track this down.

Example 1

Put a string in the replicas property, when it expects a number:

Example 2

Mistype the replicas property altogether:

Typings

Here are the types in question for this example:

• The Deployment class:

  pulumi-kubernetes/pack/nodejs/provider.ts

  Line 2924 in d6d60ca

  export class Deployment extends pulumi.CustomResource {

• Its constructor accepts a different Deployment interface type:

  pulumi-kubernetes/pack/nodejs/provider.ts

  Line 2967 in d6d60ca

  constructor(name: string, args: inputApi.apps.v1beta1.Deployment, opts?: pulumi.CustomResourceOptions) {

• This is the Deployment interface:

  pulumi-kubernetes/pack/nodejs/types/input.ts

  Line 1392 in d6d60ca

  export interface Deployment {

• It has a spec property which is of the DeploymentSpec interface:

  pulumi-kubernetes/pack/nodejs/types/input.ts

  Line 2394 in d6d60ca

  export interface DeploymentSpec {

• The replicas property of that interface:

  pulumi-kubernetes/pack/nodejs/types/input.ts

  Line 2425 in d6d60ca

  replicas?: pulumi.Input<number>

[CyrusNajmabadi]

@DanielRosenwasser Can you shed some light here? Our understanding was that TS3.0+ would help out here by whittling things down the properties that are the problem. Is there some reason that isn't happening? A config error on our side perhaps? Or is there something about these types that leads to TS feeling like it can't trim this down?

[joeduffy]

I should note that this is using TypeScript 3.0.3 for the project and VS Code is version 1.26.1 at version 3.0.1 of TypeScript (or so I assume, given that this is in the right hand corner):

Also worth noting that these types use our pulumi.Input<T> type fairly aggressively, which is a union type, and might be causing some extra troubles:

https://github.com/pulumi/pulumi/blob/1ebd698a7ab2926ef88eb97a8f268e6c95f44816/sdk/nodejs/resource.ts#L487

[DanielRosenwasser]

Sorry guys: microsoft/TypeScript#25695

Please leave feedback there and feel free to link back here!

[CyrusNajmabadi]

@DanielRosenwasser Actually, we're still seeing an issue even when not using an argument. i.e.:

Known issue as well?

[DanielRosenwasser]

I think the problem there is that we're comparing to a union type which limits our ability to confidently specialize the error. Maybe microsoft/TypeScript#26450 would help there.

[CyrusNajmabadi]

I see. That would likely definitely affect us. We have a union type which likely is the source of the issue (given the message about .apply int eh error. specifically, we call it:

type Input<T> = T | Promise<T> | Output<T>

Meaning: you can pass in a raw T value. Or you can pass something that asynchronously produces a T. Or you provide a 'node' (Output) into our graph, which itself has a value.

With our factories these types are recursively contained within themselves. After all, you could take something that asynchronously produces a value, which itself has properties which are asynchronously produced.

From a representation level, TS really makes it easy for us to describe this system. However, from an errors perspective, it really leaves a lot to be desired :) Def would love to see stuff help out here.

[lukehoban]

Is there anything we can do to improve here prior to fixes/improvements on the TypeScript side?

My assumption is unfortunately no (short of somehow not using the type Input<T> = T | Promise<T> | Output<T> union - which at this stage is not really an option).

[CyrusNajmabadi]

Moving out as i don't see anything feasible here. We're effectively at the mercy of microsoft/TypeScript#26450.

[joeduffy]

Let's just close and as TypeScript improves, we will improve. It seems there's nothing we can really do other than abandoning our union types (which clearly can't happen).