build(deps): bump node-fetch from 2.6.9 to 3.3.2

[dependabot]

Bumps node-fetch from 2.6.9 to 3.3.2.

Release notes

Sourced from node-fetch's releases.

v3.3.2

3.3.2 (2023-07-25)

Bug Fixes

• Remove the default connection close header. (#1736) (8b3320d), closes #1735 #1473

v3.3.1

3.3.1 (2023-03-11)

Bug Fixes

• release "Allow URL class object as an argument for fetch()" #1696 (#1716) (7b86e94)

v3.3.0

3.3.0 (2022-11-10)

Features

• add static Response.json (#1670) (55a4870)

v3.2.10

3.2.10 (2022-07-31)

Bug Fixes

• ReDoS referrer (#1611) (2880238)

v3.2.9

3.2.9 (2022-07-18)

Bug Fixes

• Headers: don't forward secure headers on protocol change (#1599) (e87b093)

v3.2.8

3.2.8 (2022-07-12)

Bug Fixes

• possibly flaky test (#1523) (11b7033)

... (truncated)

Commits

• 8b3320d fix: Remove the default connection close header. (#1736)
• 7b86e94 fix: release "Allow URL class object as an argument for fetch()" #1696 (#1716)
• 8ced5b9 docs: readme - non ESM example (#1707)
• 71e376b ci(release): use latest Node LTS (#1697)
• e093030 Allow URL class object as an argument for fetch() (#1696)
• 55a4870 feat: add static Response.json (#1670)
• c071406 (1138) - Fixed HTTPResponseError with correct constructor and usage (#1666)
• 6f72caa docs: fix missing comma in example (#1623)
• 2880238 fix: ReDoS referrer (#1611)
• e87b093 fix(Headers): don't forward secure headers on protocol change (#1599)
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[mstruebing]

This will require some rework, it's a major bump of node-fetch.

[brendandburns]

Presumably we need to do this in the upstream code generator anyway.

[cjihrig]

Here is the node-fetch v3 upgrade guide: https://github.com/node-fetch/node-fetch/blob/main/docs/v3-UPGRADE-GUIDE.md

There are some things that are relevant to us:

• The response.body is now nullable. That is causing most of the TypeScript errors here. I think we are safe to use response.body! in the few problematic places here though.
• Response.statusText no longer sets a default message derived from the HTTP status code. For us, this impacts the should handle error from request stream test because the 'Internal Server Error' message is no longer present.
• The timeout option was removed. This one might be trickier for us. We already have Reintroduce timeout and keep-alive for watch requests to match client-go #2131 in progress to restore keep-alive behavior, but that PR also sets requestInit.timeout, which I believe will not be valid.

Here are the current test failures with this PR and the TypeScript problems fixed:

  1) KubeConfig
       applytoFetchOptions
         should apply cert configs:
     /Users/cjihrig/programming/javascript/src/config_test.ts:272
            expect(requestInit.timeout).to.equal(5);
                                           ^

AssertionError: expected undefined to equal 5
      at Context.<anonymous> (src/config_test.ts:272:44)

  2) Watch
       should handle error from request stream:

      /Users/cjihrig/programming/javascript/src/watch_test.ts:70
        expect(doneErr.toString()).to.equal('Error: Internal Server Error');
                                      ^

AssertionError: expected 'Error' to equal 'Error: Internal Server Error'
      + expected - actual

      -Error
      +Error: Internal Server Error
      
      at Context.<anonymous> (src/watch_test.ts:70:39)
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

  3) Watch
       should not call watch done callback more than once:
     Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/Users/cjihrig/programming/javascript/src/watch_test.ts)
      at listOnTimeout (node:internal/timers:564:17)
      at process.processTimers (node:internal/timers:507:7)

  4) Watch
       should handle server errors correctly:
     Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/Users/cjihrig/programming/javascript/src/watch_test.ts)
      at listOnTimeout (node:internal/timers:564:17)
      at process.processTimers (node:internal/timers:507:7)

EDIT: The last two failures appear to be related to node-fetch v3 (unsure if it is a bug or intentional due to a spec change). Note the difference in this handler between v2 and v3. In those failing tests, the request is intentionally aborted, which triggers that 'error' handler. In v2, that would destroy the body stream. Without that happening, there doesn't appear to be a way for us to trigger the doneCallOnce function in watch.ts.

[cjihrig]

@dependabot recreate

[cjihrig]

/hold

[brendandburns]

@dependabot rebase

[dependabot]

Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't rebase it - sorry!

If you're happy for Dependabot to recreate it from scratch, overwriting any edits, you can request @dependabot recreate.

[k8s-ci-robot]

rebase

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[cjihrig]

@dependabot recreate

[brendandburns]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: anandfresh, brendandburns, dependabot[bot]

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [brendandburns]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cjihrig]

@brendandburns I have this PR marked as "do not merge" because I'm not sure that we should update to node-fetch v3 in this repo until we have proper support in the code generator.

Do we have any idea if the code generator has support for v3?

[brendandburns]

I was assuming that because the typescript compiles that it works correctly. If our tests pass, but the real usage would fail, I think we need to update our tests.

We shouldn't be in a state where tests pass, but real usage fails.

I'll checkout this branch locally and give it a try.

[cjihrig]

Yea, to be clear, I did not try any real world usage with node-fetch v3. I think if the code generator works with v3, we should try adding an option (if one does not already exist) to use it so that the support feels more official.

[vladshcherbin]

Instead using external node-fetch library with a major version bump why not just use native fetch in nodejs?

[cjihrig]

I think that is the end goal. I think it would be great because we could drop a number of dependencies which are increasingly painful to keep up with.

fetch() in core is technically experimental in Node 18 and 20 though. Node 18 will be end-of-life in a couple months, but Node 20 still has over a year of life left.

[vladshcherbin]

I don't think there is any reason to wait until node 20 end of life. node-fetch last update was almost 2 years ago and core member says there's no reason to use the library after node 16 end of life.

[cjihrig]

So, even Node 18 does not print an experimental warning when fetch() is used. However, Node 18 does use an older version of undici internally. The most recent Node 20, 22, and 23 all use the same version of undici internally despite fetch() being experimental in 20 still. I'd personally be OK with using native fetch on v20. We would still need to update the code generator in this repo though.

[k8s-ci-robot]

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[brendandburns]

Yeah, I'm ok to move to the internal fetch, we can start the move now and make it part of the next release when Kubernetes 1.33 drops (4/23/25)

[brendandburns]

I'm going to close this since we're going to switch to node internal fetch.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.