consider switching from got to ky

[travi]

https://www.npmjs.com/package/ky

from the got readme:

You probably want Ky instead, by the same people. It's smaller, works in the browser too, and is more stable since it's built upon Fetch.

i've used ky in a few projects now and it has been solid. would it make sense to switch here?

[fgreinacher]

Sure, why not.

What comes immediately to my mind when switching HTTP libraries is whether the properly support proxy env variables. That is often causing issues. Do you have experience with that?

[JonasSchubert]

I am going to test it. I switched a package from got to ky and going to monitor it. Proxy settings can be forwarded to the node fetch method as far as I understood it.
Will come back here, once I have tested more.

[JonasSchubert]

I am going to test it. I switched a package from got to ky and going to monitor it. Proxy settings can be forwarded to the node fetch method as far as I understood it. Will come back here, once I have tested more.

After using my updated package now for a few days, here a short summary:

• theoretically the proxy settings can be forwarded to node-fetch, thanks to this PR
• ky will not receive builtin proxy support though
• I (naively) have tried the current approach also in my lib, but it did not work (probably expected)
• I have successfully used this approach with undici's experimental EnvHttpProxyAgent

As the EnvHttpProxyAgent is still experimental I do not think we should use this in this library. Mine is a minor one without widespread usage, but semantic-release should be stable and not use an experimental library.

I will have one more look into configuring without this library, but it might take time as I am fine with my current setup and limited time.

[JonasSchubert]

I am going to test the changes. I have switched a package from got to ky and will monitor the results. As far as I understand, proxy settings can be forwarded to the node-fetch method.

I will update here once I have conducted more tests.

Let me know if you'd like any further tweaks!

jenkinsci/docker#1971 (comment)

Duplicate of #1531

Also, please do not use an LLM to generate content wasting maintainers time. We expect a proper discussion and due diligence in searching existing issues. Additionally, the problem has to be treated on the www.jenkins.io and adding an eventual link in this repository.

This applies also here.

[fgreinacher]

As the EnvHttpProxyAgent is still experimental I do not think we should use this in this library. Mine is a minor one without widespread usage, but semantic-release should be stable and not use an experimental library.

@JonasSchubert EnvHttpProxyAgent is stable now, see nodejs/undici#4049. WDYT should we move forward with this?

[JonasSchubert]

As the EnvHttpProxyAgent is still experimental I do not think we should use this in this library. Mine is a minor one without widespread usage, but semantic-release should be stable and not use an experimental library.

@JonasSchubert EnvHttpProxyAgent is stable now, see nodejs/undici#4049. WDYT should we move forward with this?

I also have no problems in my NPM package with EnvHttpProxyAgent. I can create a PR in the next days, if nobody else would take that?

[fgreinacher]

I can create a PR in the next days, if nobody else would take that?

@JonasSchubert Yes, that would be awesome!

[ievgennaida]

out of the curiosity, why default http lib cannot be used?