axios-fetch

Bridges an existing Axios client into the WebAPI Fetch interface so Fetch-only libraries can reuse your Axios setup.

Library
npm
v3.1.0
174stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
51/100Fair
Development Activity32
Maintenance20
Community72
Maturity60
Momentum20

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
56/100Fair
Architecture72
Code Quality85
Innovation38
Learning Curve30

@lifeomic/axios-fetch wraps an existing Axios instance in a function matching the WebAPI fetch signature, so libraries that expect a Fetch implementation — like Apollo Link HTTP — can be pointed at an Axios client instead of a native fetch or a polyfill. It normalizes header handling between the two APIs (case-folding, Headers objects, header arrays, or plain objects), forces the response body type to arraybuffer so the resulting Response still supports .json()/.text() correctly, and converts Axios errors that carry an HTTP response back into a normal Response instead of letting them reject the returned promise.

An optional transformer callback lets callers rewrite the derived Axios request config before it is dispatched, which is how the library supports forcing timeouts, applying auth headers, or reusing Axios interceptors — all without configuring a second, differently-behaved HTTP client alongside an existing Axios setup.

What You Get

  • buildAxiosFetch factory - wraps any Axios instance, including ones with interceptors already attached, into a drop-in fetch-compatible function.
  • Header normalization - converts between Headers objects, header arrays, and plain objects in both directions, lower-casing names and defaulting content-type when none is set.
  • Request transformer hook - an optional typed callback to mutate the derived Axios config (timeouts, auth, custom fields) before the request is sent.
  • Error-to-response bridging - Axios errors that carry an HTTP response are converted back into a Response instead of being thrown, matching Fetch semantics for non-2xx status codes.

Common Use Cases

  • Apollo Link HTTP integration - point createHttpLink({ fetch: buildAxiosFetch(axiosInstance) }) at an existing Axios client instead of configuring a separate fetch polyfill.
  • Migrating fetch-only libraries onto Axios - reuse Axios-specific tooling (interceptors, retry logic, auth refresh) for third-party libraries that only accept a Fetch implementation.
  • Enforcing consistent request behavior - use the transformer hook to apply a shared timeout or header policy across every Fetch-shaped call in an app.
  • Keeping Axios-oriented test mocking - continue using Axios-focused mocking tools like nock for code paths that technically call a Fetch interface.

Under The Hood

Architecture The library is a single curried factory: buildAxiosFetch(axios, transformer?) returns an async function matching the Fetch call signature. Internally, axiosFetch in src/index.ts converts Fetch-style input/init arguments into an Axios request config, delegating header translation to dedicated helpers (createAxiosHeaders, createFetchHeaders, getUrl) in src/typeUtils.ts, and reconstructs a WebAPI Response from whatever Axios returns (or from err.response on an HTTP error). Axios’s own request/response types are re-declared locally in src/axios-types.d.ts rather than imported from the axios package, decoupling the adapter’s public types from any specific installed Axios version. The separation between config-building, header conversion, and response reconstruction is clean given the small surface area, though the whole request/response bridge lives in one function rather than being split into named stages.

Tech Stack Written in TypeScript (strict mode, noUncheckedIndexedAccess, strictNullChecks) targeting ES2017 with CommonJS output; tsc compiles src/*.ts in place for publishing (main/types point at the compiled src/index.js/src/index.d.ts). Axios itself is not a runtime dependency — only @types/node-fetch is declared as a real dependency, so the consuming application is expected to supply its own Axios instance and Response global (the README shows polyfilling global.Response from node-fetch for non-browser environments). Testing uses ava with ts-node/register, nock for HTTP mocking, sinon for spies/stubs, and nyc for coverage; linting is eslint with @lifeomic/eslint-plugin-node and @typescript-eslint.

Code Quality nyc is configured to require 100% line, statement, function, and branch coverage per file, and the test suite in test/index.test.ts exercises both success and failure paths by running every case through the real node-fetch implementation and the Axios-backed adapter side by side (dualFetch), asserting the two responses match — covering header casing, undefined header values, text/JSON/multipart bodies, HTTP error status codes, network errors, request transformers, and Axios interceptor compatibility. Types are strict throughout with no any leakage in the public API. CI runs lint, type-check (postlint), and tests via GitHub Actions (pr-build.yaml, release.yaml), plus a scheduled code-scanning workflow.

What Makes It Unique The adapter pattern itself is standard, but the implementation is unusually careful about edge cases that most quick Axios-to-fetch shims skip: it forces arraybuffer response typing specifically to avoid Axios guessing content types and adding headers that weren’t in the original response, explicitly handles header arrays/objects/Headers instances symmetrically in both directions, and treats Axios’s error-with-response case as a valid Fetch response rather than a thrown error — matching how fetch itself never rejects on HTTP error status codes.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search