Skip to content

fix: support edge/serverless runtimes via axios adapter fallback (#31) - #107

Merged
Mantas97 merged 2 commits into
mailerlite:mainfrom
CedricConday:fix/edge-runtime-fetch-adapter
Aug 5, 2026
Merged

fix: support edge/serverless runtimes via axios adapter fallback (#31)#107
Mantas97 merged 2 commits into
mailerlite:mainfrom
CedricConday:fix/edge-runtime-fetch-adapter

Conversation

@CedricConday

Copy link
Copy Markdown
Contributor

Problem

The SDK throws in runtimes that don't ship Node's http module — Vercel Edge Functions, Cloudflare Workers, Next.js edge routes, Deno — because axios can't find a usable adapter (reported in #31):

AxiosError: There is no suitable adapter to dispatch the request since :
- adapter xhr is not supported by the environment
- adapter http is not available in the build

Fix

axios ≥ 1.7 accepts an ordered list of adapters and selects the first one supported by the current runtime. All requests already funnel through a single request() helper (src/utils/fetch.ts), so one change covers the whole SDK:

adapter: ["http", "xhr", "fetch"]
  • Node → keeps using http (no behaviour change; all recorded-tape tests stay green)
  • Browsers → keep using xhr
  • Edge / serverless (no http/xhr) → transparently fall back to the universal fetch adapter

No new dependencies, no breaking changes, no major version needed. axios@^1.15.0 (already the declared dependency) ships the fetch adapter.

Tests

  • Added src/utils/fetch.test.ts — a self-contained unit test (mocks axios, no network/API key) asserting the adapter fallback order.
  • Full existing suite still passes (40 tape-replayed tests green; Node continues to select http).

Docs

Added a short Edge & serverless runtimes note to the README.

Fixes #31

🤖 Generated with Claude Code

https://claude.ai/code/session_01DbUHs855FyBt2J7cG2Qmhh

…lerlite#31)

The SDK hard-failed in runtimes that don't ship Node's `http` module
(Vercel Edge, Cloudflare Workers, Next.js edge routes, Deno) with
`AxiosError: There is no suitable adapter to dispatch the request`.

axios >= 1.7 can be given an ordered list of adapters and picks the
first one supported by the current runtime. Passing
`["http", "xhr", "fetch"]` keeps Node on `http` and browsers on `xhr`
(no behaviour change), while edge/serverless runtimes that ship neither
transparently fall back to the universal `fetch` adapter.

Adds a self-contained unit test (mocks axios, no network) and documents
edge support in the README.

Fixes mailerlite#31

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DbUHs855FyBt2J7cG2Qmhh

@Mantas97 Mantas97 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@CedricConday Clever solution for the problem 👍 Just one detail that needs to be addressed

Comment thread src/utils/fetch.ts Outdated
Comment thread src/utils/fetch.test.ts
`body` defaults to null, so `body && JSON.stringify(body)` passed
`data: null` on bodyless calls. Node's http adapter tolerates that;
workerd rejects a GET/HEAD Request carrying any body property, which
broke every read call on Cloudflare Workers once the fetch adapter was
in play.

Adds a regression test that fails on the old form (expected undefined,
received null) and one asserting bodies still serialize.

Co-Authored-By: Claude <noreply@anthropic.com>
Assisted-by: Claude Opus 5

@Mantas97 Mantas97 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great 👏 Thanks for contributing!

@Mantas97
Mantas97 merged commit 9dd4703 into mailerlite:main Aug 5, 2026
Comment thread src/utils/fetch.test.ts
const passedConfig = axiosMock.mock.calls[0][0] as { adapter: unknown };
// Ordering matters: Node/browser keep their existing adapter, while
// edge/serverless runtimes fall back to `fetch`. See issue #31.
expect(passedConfig.adapter).toEqual(["http", "xhr", "fetch"]);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This tests that the implementation has this particular array, but doesn't actually test the behavior. The correct test would be to create an integration test that uses the library from deno.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Library is not compatible with CloudFlare Workers / Vercel Edge functions

3 participants