Thanks for pointing this out. I'm not sure where that came from... I will dig in and see what we need to do to fix it.

Note that you can always pass the number as a string (e.g. "123") the code will do the right thing.

Thanks for responding. Passing as string doesn't pass the type check too, string doesn't conform to object. Probably need to use any.

I found a similar issue with ExtensionsV1beta1IngressBackend. In that type definition, servicePort is listed as object but it should really be number | string. You can see where the confusion may be coming from if you look at the swagger.json code found here:

...
    "io.k8s.api.networking.v1beta1.IngressBackend": {
      "description": "IngressBackend describes all endpoints for a given service and port.",
      "properties": {
        "serviceName": {
          "description": "Specifies the name of the referenced service.",
          "type": "string"
        },
        "servicePort": {
          "$ref": "#/definitions/io.k8s.apimachinery.pkg.util.intstr.IntOrString",
          "description": "Specifies the port of the referenced service."
        }
      },
      "required": [
        "serviceName",
        "servicePort"
      ],
      "type": "object"
    },
...

Specifically, note the "$ref": "#/definitions/io.k8s.apimachinery.pkg.util.intstr.IntOrString",. I suspect that what ever automatic process is used to generate the TypeScript definitions, it gets confused by the $ref here and doesn't translate it into the correct type.

This is preventing me from being able to upgrade to 0.11.0 as well. Are there any updates as to when this will be resolved?

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/lifecycle frozen

This issue is essentially making the node client unusable, cannot set an ingress because servicePort is incorrectly typed as object, cannot use a clusterIP because targetPort is incorrectly typed as object. Is there any update on this?🙏

I am seeing the same problem with V1RollingUpdateDaemonSet.maxUnavailable
Neither string nor number are assignable to object.

For any others reading this, this is how I hacked my way around this issue:

port.targetPort = (8000 as unknown) as object;