it seems like at some point, these properties were not supposed to be returned if verbose: true was not passed, however, they are being returned.

Also, we probably shouldn't be asserting the lack of a property.. only the existence of properties.

When verbose is not true, Kubo does not return values for them (JSON keys are present, but with empty/default value):

$ ipfs swarm peers --enc=json | jq
{
      "Addr": "/ip4/97.115.80.237/udp/57908/quic",
      "Peer": "12D3KooWMMnfUUJBzZEA6rv6NyN6QUdJaRk62bc9zECXJNmKYPNP",
      "Latency": "",
      "Muxer": "",
      "Direction": 0,
      "Streams": null
    }

so what you want to test here is to ensure they have these empty values when verbose is not passed.

Q: when we run Node with this, does it impact the runtime of tests, or is it run in a separate process?

(if it is the same process, it is a problem: we should be running tests with default Node LTS and no special parameters)

I'm not sure I fully understand your question, but I'll give some context around this:

1. nodeJS 18 (not being tested currently for node tests in ipfs-http-client, so scope creep for this task) adopted native fetch, see https://nodejs.org/en/blog/announcements/v18-release-announce/#fetch-experimental.
   • This was previously under an opt-in flag --experimental-fetch, but in 18 was switched to opt-out with --no-experimental-fetch. Basically, any discrepancies between node-fetch and undici's fetch will need to be handled if we don't override global fetch in node with node-fetch.
   • I have a hunch that some of these discrepancies were one of the problems I had with unblocking the test/node/agent.js test.
2. When we run tests, the flow is:
   • node run test
   • which runs aegir test
   • which kicks off execa(subprocess) for either c8 or mocha
     • c8 or mocha: https://github.com/ipfs/aegir/blob/7c5be7fc1690ca0054e3b4dcd0d99c5f083e25d1/src/test/node.js#L21
     • env passed to the subprocess: https://github.com/ipfs/aegir/blob/7c5be7fc1690ca0054e3b4dcd0d99c5f083e25d1/src/test/node.js#L77

I think item 2 above tells us the answer to your question is that this is a separate process.

⚠️

This project is managed via github.com/protocol/.github (config).

Does this mean the changes to this file from this PR will be overwritten by https://github.com/protocol/.github/blob/master/templates/.github/workflows/js-test-and-release.yml the next time CI sync runs?

I believe it will be overwritten:

• when repo is added to unified CI (this repo has already been)
  https://github.com/protocol/.github/blob/30836503d140fec6454ef6f49d96372a9167757f/.github/actions/add-unified-ci-to-new-go-repos/src/main.ts
• copy workflow from .github repo: https://github.com/protocol/.github/blob/b1a2633be4742ee57b26f27ef475d5227b585476/.github/workflows/copy-workflow.yml
• code where unified CI compares existing workflows to templated workflows in .github repo: https://github.com/protocol/.github/blob/b1a2633be4742ee57b26f27ef475d5227b585476/.github/workflows/copy-workflow.yml#L115-L124

@galargh can you confirm?

Yes, it's going to get overwritten. Whenever https://github.com/protocol/.github/actions/workflows/dispatch.yml runs, it updates uCI files in all the repositories where it's configured (if needed of course). That's why files managed by uCI have this header:

Here's an automated PR that wants to update the workflow here: #85 (it would have been automerged if only test-node on windows passed).

If there's a change we want to introduce that would benefit all JS repos participating in uCI, then this would be the place to do it: https://github.com/protocol/.github/blob/master/templates/.github/workflows/js-test-and-release.yml

Side note: the way Unified CI provisions files is different from how GitHub Management does it. For example, if we were to modify https://github.com/ipfs/js-kubo-rpc-client/blob/master/.github/workflows/stale.yml which is managed here https://github.com/ipfs/github-mgmt/blob/eed32757b57354659c07d738d36ecfbc25a033ef/github/ipfs.yml#L4589-L4591, then the next sync would have noticed that the two diverged and would update the content in the YAML config.

So if a project needs to disable node LTS or other node versions for some reason, what is the best way to accomplish that?

Can we make the unified CI workflow dynamic with a default to LTS? I'm not sure the best way to accomplish this but it would allow individual projects to update/override when necessary. Without being overwritten.

When verbose is not true, Kubo does not return values for them (JSON keys are present, but with empty/default value):

$ ipfs swarm peers --enc=json | jq
{
      "Addr": "/ip4/97.115.80.237/udp/57908/quic",
      "Peer": "12D3KooWMMnfUUJBzZEA6rv6NyN6QUdJaRk62bc9zECXJNmKYPNP",
      "Latency": "",
      "Muxer": "",
      "Direction": 0,
      "Streams": null
    }

so what you want to test here is to ensure they have these empty values when verbose is not passed.