cleanup(deps): Consideration of removing an unnecessary dependency (abort-controller)

[SandZn]

Hi,

I'm doing research on detecting unnecessary dependencies in NodeJs packages. I found that one dependency (abort-controller) is not necessary for your package.

I modified the package.json file to remove the abort-controller dependency, and I ran your tests. The testing result showed that all tests passed, and the test coverage did not change before and after I removed this dependency.

Would you consider removing this dependency to enhance security and reduce maintenance costs?

[ddelgrosso1]

Hi @SandZn unfortunately I do not think this is possible at this time. This library currently supports Node >= 12. AbortController did not become stable in Node until v15.4.0 . I am assuming you tested with a version >= 15.4.0 is that correct?

[SandZn]

Correct. My node version is v16.17.0. Thank you for your response.

[ddelgrosso1]

@SandZn I'm going to keep this issue open and just update the title a bit to reflect the desire. When we move minimum node versions we would certainly be happy to remove abort-controller.

[manzonif]

Hi! 👋 We’re still experiencing this issue in recent versions of @google-cloud/storage, especially in ESM environments (e.g. Angular Universal / SSR with Node.js 20+).

Even though PR #1889 addressed the removal of the abort-controller polyfill, the current build of the package (e.g. build/src/resumable-upload.js) still imports:

import AbortController from 'abort-controller';

This causes runtime errors like:

Error: Expected signal to be an instanceof AbortSignal

when calling methods such as file.save() or file.download() after an AbortController was used in the SSR rendering context.

In modern Node.js (>=18), a native AbortController is already available globally and works correctly. However, the library’s bundled ESM build forces the use of the old polyfill, which produces a non-standard AbortSignal instance that breaks compatibility.

For now, patching the import (removing the abort-controller dependency) fixes the issue entirely.

Would it be possible to:

Remove the abort-controller dependency for Node 18+ (where native support exists),

Or conditionally import the polyfill only when globalThis.AbortController is missing?

This would improve compatibility and eliminate the need for manual patching in modern ESM / SSR environments.

Thanks a lot for keeping this package solid — it’s a key dependency for many Node SSR workflows 🙏

[tushuhei]

+1 to remove abort-controller. This issue broke my SvelteKit / AppEngine / Node.js 22 setup. @ddelgrosso1 Do you have a plan to move the minimum supported Node.js version to v16 or above?

[ddelgrosso1]

@tushuhei yes there are still plans to move this library off of Node 14. cc: @thiyaguk09 who might be able to add more clarity as I no longer work directly on this library.

[thiyaguk09]

The abort-controller has been removed from the Node 18 upgrade workflow, since this issue will be addressed with the Node 18 release.

[tushuhei]

Thank you @thiyaguk09 !

[ddelgrosso1]

Reopening because while this has been merged to the Node 18 branch it has not been released to the public.