Below is an explanation and some strategies to avoid bundling server‑only code into your client bundle.

---

What’s Happening

Even though your dynamic import of the cookieFetcher module is inside an if block that checks whether a cookie was passed, the module still ends up in the client bundle. This is because your fetcher function is imported by both server and client modules so its complete dependency graph is analyzed at build time. As a result, even unused code (or code only dynamically imported on the server) shows up in the module graph, and Next.js may try to bundle it on the client side.

---

Recommended Solutions

1. Separate Client and Server APIs

Create two separate fetcher functions: one for server components that uses the server‑only cookie logic and one for client components that expects to receive the cookie.

For example:

JAVASCRIPTCopied
// server/fetcher.ts (Server-only)
import 'server-only'
import CookieStore from '../classes/cookieFetcher'

export const serverFetcher = async (endpoint: string) => {
  const cookie = await CookieStore.get('somedeliciouscookie')
  // call your endpoint with the cookie
  // ...
}

JAVASCRIPTCopied
// client/fetcher.ts (Client-only)
export const clientFetcher = async (endpoint: string, cookie: string) => {
  // use the provided cookie to call your endpoint
  // ...
}

Then, each component can import the appropriate version.

2. Move Server‑Only Code Into a Separate Module

If you want to keep a single entrypoint, shift the server‑only parts into a module that is only imported on the server.

JAVASCRIPTCopied
// fetcher.server.ts (Notice the ".server" naming convention)
import CookieStore from '../classes/cookieFetcher'

export const fetchWithAutoCookie = async (endpoint: string) => {
  const cookie = await CookieStore.get('somedeliciouscookie')
  // call your endpoint with the cookie
  // ...
}

Then have your public fetcher choose between the two based on the environment:

JAVASCRIPTCopied
// fetcher.ts
export const fetcher = async (endpoint: string, autoCookie?: string) => {
  if (!autoCookie) {
    // This file is named *.server.ts so it won’t be bundled in client code
    const { fetchWithAutoCookie } = await import('./fetcher.server')
    return fetchWithAutoCookie(endpoint)
  } else {
    // Use auto-injected cookie for client-side
    // ...
  }
}

By moving the server-only dependency (i.e. your module that uses “next/headers”) into a file with the “.server” suffix (or into a module where you use the server-only package), Next.js will know that it should never be included in the client bundle.

3. Use Environment Checks (with Caution)

You can perform an environment check (e.g. if (typeof window === 'undefined')) to ensure that your code path using server-only modules is never reached on the client. However, even with this check, if your fetcher function is imported into a client component the static dependency may still bleed in. To avoid this completely, it’s best to follow one of the above patterns and isolate the server code.

---

Summary

To avoid having server-only modules (like one using "next/headers") bundled when your fetcher is imported in a client component, try to either:

• Split your fetcher into two different implementations (client and server).
• Move server-only functionality into a separate module (or file with a .server.ts extension) so that it isn’t included in the client bundle.
• Use the server-only package on your server-only modules if sharing the same file structure is needed.

These approaches ensure that your server-only code isn’t inadvertently sent to the browser—keeping your sensitive operations and private variables secure and your application error‑free.