Cookie handling for fetch in Node.js - small CookieJar plugin for Luminara

[miller-28]

Hi everyone,

For anyone building on top of fetch in Node.js or server side environments and struggling with cookies, I released a small plugin that might help.

In the browser, cookies are handled for you.
On the server, if you use fetch (Node 18+ or undici), you need to:

• capture Set-Cookie headers
• store cookies in a jar
• send the correct Cookie header per request
• keep behavior consistent across retries, hedging, and multiple clients

I built luminara-cookie-jar, a CookieJar plugin for my HTTP client Luminara, to solve this in a clean way using tough-cookie.

Key points:

• automatic Set-Cookie capture on responses
• automatic Cookie injection on requests
• shared jars across multiple clients when needed
• full CookieJar API exposed via client.jar for advanced use
• integrates with retries, hedging, timeouts and stats in Luminara

Minimal example:

import{createLuminara}from"luminara";import{cookieJarPlugin}from"luminara-cookie-jar";constclient=createLuminara({baseURL: "https://api.example.com",plugins: [cookieJarPlugin()]});// login - cookies stored automaticallyawaitclient.post("/login",{username: "user",password: "pass"});// cookies are sent automatically on the next callconstprofile=awaitclient.get("/profile");// direct access to the jar if neededconsole.log(awaitclient.jar.getCookies("https://api.example.com"));

Repo: https://github.com/miller-28/luminara-cookie-jar
npm: https://www.npmjs.com/package/luminara-cookie-jar

If you are using fetch on the server and need browser-like cookie behavior, this might be useful.

[Mohataseem89]

curious does it handle cookies across redirects automatically (similar to browser fetch)?

also how iss performance when sharing jars across multiple clients under load? I have seen tough-cookie get a bit heavy in high-throughput cases, so wondering if you’ve optimized that in your implementation.

either way this looks like a clean solution to a long-standing Node fetch pain point

[miller-28]

Thanks — good questions! I checked the luminara-cookie-jar code and tests and here’s what I found:

The plugin attaches a tough-cookie CookieJar to client.jar, injects cookies into outgoing requests (onRequest), and stores Set-Cookie headers from responses into the jar (onResponse). There are explicit tests and README examples showing a shared CookieJar between multiple clients and asserting real-time sync.

Redirects: the plugin will persist any Set-Cookie headers it actually receives. If Luminara (or the underlying fetch) exposes intermediate redirect responses to the plugin’s onResponse hook, cookies set during redirects will be captured and used on subsequent requests. If redirects are followed internally and intermediate responses (and their Set-Cookie headers) are not exposed to plugins, those cookies won’t be captured. The repo doesn’t include an explicit redirect test, so behavior depends on how redirects are surfaced by your Luminara/fetch configuration.

Performance under load: the plugin itself does no special optimizations — it just calls tough-cookie’s jar.getCookieString and jar.setCookie (wrapped into promises). tough-cookie is robust, but in high-concurrency, high-throughput scenarios a single shared in-memory CookieJar can become a contention point. If you expect heavy load, consider:
Using separate jars per client or worker where session isolation is acceptable.
Sharding or partitioning cookie state to reduce contention.
Implementing a custom cookie store (e.g., a Redis-backed store or a specialized in-memory store) tailored for concurrency.
Benchmarking getCookieString/setCookie on your workload to measure where the bottleneck is.

[kayarkar007]

Great question! This is a very practical solution for Node.js cookie handling. A few additional thoughts that might help others:

1. Session Isolation Pattern: When handling multiple users/sessions, consider a cookie jar pool to keep sessions isolated from each other, preventing cross-contamination.

2. Memory Management: Implement automatic cleanup of expired cookie jars to prevent memory leaks in long-running servers. Check and delete jars that haven't been accessed for a certain time.

3. Alternative Libraries: For teams new to this, libraries like got (built-in cookie support) or axios with tough-cookie offer simpler implementations for basic CRUD operations.

4. Performance Considerations: The tough-cookie library is solid but can have overhead under high concurrency. Consider Redis or in-memory caching for frequently accessed cookies.

Your Luminara plugin looks like an excellent abstraction for Luminara-specific needs. The implementation details you shared (automatic Set-Cookie capture, redirect handling) are exactly what teams need for production systems.