Request is fully deprecated as of February 11 2020.

[cmosgh]

As stated here request is fully deprecated. The reasons are described in this issue .
I think it is the time to choose an alternative, considering this kubernetes client is used on some production applications.

These are the current alternatives.

[brendandburns]

This is generated by the open api code generator. Looks like we could switch to Axios. Is there a preference for a particular HTTP client library?

[chadbr]

Axios is pretty "big"... The "replacement" is https://github.com/mikeal/bent

but I haven't tried it yet...

[brendandburns]

Unfortunately to use an alternate library it needs to first be integrated into the code generator that we use:

https://github.com/OpenAPITools/openapi-generator

[chadbr]

Maybe Fetch? https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java

[brendandburns]

We could try fetch, but it's not node native, so we'd have to use the node-fetch package (not a blocker though)

I will look into this.

[brendandburns]

Switching to fetch is going to be broken until this issue is resolved somehow:

OpenAPITools/openapi-generator#3694

The generator is going to generate a broken path.

[fejta-bot]

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

[chadbr]

/remove-lifecycle stale

[jschluchter]

Not sure what the movement is here, but can I suggest got https://www.npmjs.com/package/got ?

[d-cs]

@jschluchter GOT looks nice but unfortunately doesn't have a openapi client generator.

[d-cs]

I am currently exploring how to resolve #165 it looks like the decision made here could impact that.

To choose a library to make the HTTP calls we need to choose one of the following:

• typescript-angular
• typescript-aurelia
• typescript-axios
• typescript-fetch
• typescript-inversify
• typescript-jquery
• typescript-node
• typescript-redux-query
• typescript-rxjs

Ignoring the deprecated and experimental ones. Also ignoring the JavaScript ones as having the types for such a large API is certainly useful.

I would say that typescript-angular would prevent developers of other popular frontend frameworks would be locked out. I'm also not sure about it working on NodeJS environments as it uses an Angular library to make HTTP requests (see here).

typescript-aurelia could need to be polyfilled and bundled for the browser (see here). Although I'm not 100% sure this is true, it might be a boilderplate README.md file.

@chadbr what makes typescript-axios big? The outputted JS is huge when you run it against the k8s API? There is a configuration option that splits the outputted code out into individual files rather than one big one, I got that working locally and could share the output? Or are you talking about the bundle size?

We'll rule out typescript-fetch for the reasons @brendandburns mentions above.

typescript-inversify uses fetch under the hood so again we'd need to handle how this works on NodeJS.

typescript-node uses the native http library which is why the browser side support ticket exists.

typesript-redux-query would oblige the user to use Redux.

typescript-rxjs this uses ajax under the hood. This seems to have some compatibility issues with NodeJS, requiring extra libraries.

With that in mind we have the following:

Suitable Candiate

Would be a good replacement, working for both front and backends.

• typescript-jquery

May be Suitable

Subject to questions raised.

• typescript-axios

Would work with compatibility changes

With further work for NodeJS

These libraries would need some additional work to make compatible with NodeJS.

• typescript-rxjs
• typescript-inversify
• typescript-fetch

With further work for Browser

These libraries would need some additional work to make compatible with the browser.

• typescript-node
• typescript-aurelia

Not suitable

• typescript-angular
• typescript-redux-query

This is based on my observations, I've tried to back up claims where possible. I'm happy to attempt the refactor but before going too far I'd like to be sure that we made the right decision.