do not import gcp-metadata rabbithole, if not needed

[jeldeklint]

Cloud run imports are slow as is. Do not make it worse.
gcp-metadata pulls gaxios and json-bigint, always.
Should also be replaced with

const metadata = await fetch("http://metadata.google.internal/computeMetadata/v1/project/project-id", {
    headers: {
    "Metadata-Flavor": "Google",
  },
});

since node 18+ is required.

[jeldeklint]

test-coverage seems drunk?

[assensamuelsson]

LGTM! Nice catch.

Is it really a good idea for us to force 100% code coverage?
When submitting PR's like this it is frustrating when not getting passed Github Actions for this reason.

We can track and report it somehow if we want to - but I vote for not having it as a requirement.

[wisko]

Regarding coverage: I think we can remove all ignore-coverage comments if we lower it to 90.

I think we should change gcp lib to optional dependency if we revert to importing this dynamically. Alternatively add it as an argument to the middleware, so that its the implementors responsibility to either set the env variable or pass an argument with the name. Thoughts?

[jeldeklint]

I think we should change gcp lib to optional dependency if we revert to importing this dynamically. Alternatively add it as an argument to the middleware, so that its the implementors responsibility to either set the env variable or pass an argument with the name. Thoughts?

I think it will be less headaches to keep it in node_modules but maybe not using it. Removing an env can happen without rebuilding, or the same image being used in several places. Filesize is probably in KBs, it's the accesstime I want to avoid. (especially since it multiplies with depth)

[MattiasOlla]

I think we should change gcp lib to optional dependency if we revert to importing this dynamically. Alternatively add it as an argument to the middleware, so that its the implementors responsibility to either set the env variable or pass an argument with the name. Thoughts?

I think it will be less headaches to keep it in node_modules but maybe not using it. Removing an env can happen without rebuilding, or the same image being used in several places. Filesize is probably in KBs, it's the accesstime I want to avoid. (especially since it multiplies with depth)

I actually tried making it an optional dependency at first, but changed it due to optional dependencies being a pain to work with in node (I never thought I'd miss Python's dependency management).

I also absolutely agree that using fetch directly would be better, as long as we make sure that everything still works locally/when used outside of GCP, even when the env variable is not set.

[jeldeklint]

I think we should change gcp lib to optional dependency if we revert to importing this dynamically. Alternatively add it as an argument to the middleware, so that its the implementors responsibility to either set the env variable or pass an argument with the name. Thoughts?

I think it will be less headaches to keep it in node_modules but maybe not using it. Removing an env can happen without rebuilding, or the same image being used in several places. Filesize is probably in KBs, it's the accesstime I want to avoid. (especially since it multiplies with depth)

I actually tried making it an optional dependency at first, but changed it due to optional dependencies being a pain to work with in node (I never thought I'd miss Python's dependency management).

I also absolutely agree that using fetch directly would be better, as long as we make sure that everything still works locally/when used outside of GCP, even when the env variable is not set.

Yes! Saw it! :D since gcp-metadata uses 169.254.169.254 or the internal host, it will fail outside of GCP anyway? We could just set the time out to like 5ms or such since the metadata api should respond very fast.