@polymarket/client's published bundle is not tree-shakable — needs sideEffects: false + per-module ESM (or a separate perps entry)

[cucumber-sp]

The published @polymarket/client ships as a tsup-prebundled dist/ where every import path — the root, /actions, /viem — funnels through one monolithic shared chunk (dist/chunk-*.js, ~147KB unminified) that contains perps, RFQ/combos and websocket-subscription logic alongside the auth/approvals code.

Measured in our production build (Vite/Rolldown, but the mechanism is bundler-independent): using only createSecureClient, credential handling and the trading-approvals actions, we still ship 162KB minified / 44KB gzip of the client — ~80% of that shared chunk — with perps identifiers (perpsDepositContract, perpsSubscriptions, ArmPerpsAutoCancelError, combo types, …) surviving dead-code elimination into the final bundle. Subpath imports don't help because the subpaths re-export from the same chunk; /actions is a flat 150+-name barrel resolving into it.

Ask: publish with sideEffects: false and real per-module ESM output (preserveModules or equivalent), and/or split perps/RFQ into their own entry point or package — so consumers touching only the auth/trading surface don't pay for the rest. Happy to provide the full byte-attribution breakdown if useful.

[cesarenaldi]

This is a valid observation, and the intended behaviour for the public interface of this package. @polymarket/client is intended primarily for Node.js and other server-side integrations, so client-side bundle size and tree shaking are not its main packaging target.

For browser integrations, the upcoming @polymarket/react package is being designed to be fully tree-shakeable. It integrates the raw action functions on demand, binding each action to the appropriate underlying public or secure client instance rather than importing the full client surface.

That work is still in progress, but the composition pattern will become clearer as more of the React package lands.

[osr21]

Confirmed — and a working bypass for perps + RTDS-only consumers

We ran into this building a perps dashboard that only needs: RTDS TWAP subscriptions, `/v1/info/instruments`, `/v1/info/tickers`, `/v1/info/klines`, and `/v1/info/funding`. No CLOB order placement, no viem integration, no auth/approvals code needed.

After hitting the 162KB bundle cost you describe, we bypassed `@polymarket/client` entirely for all perps data paths and wrote thin fetch wrappers directly against `api.perpetuals.polymarket.com` and `ws.perpetuals.polymarket.com`. The result: **~3KB** for all perps data access (instruments + tickers + klines + funding + WebSocket BBO/trades/klines), zero client overhead.

The raw WebSocket subscription format (for anyone who wants to skip the SDK while the tree-shaking issue is open):

```ts
// wss://ws.perpetuals.polymarket.com/v1/ws
ws.send(JSON.stringify({ req: "sub", chs: ["bbo::1", "trades::1", "klines::1::1m"] }));

// wss://ws-live-data.polymarket.com  (RTDS — Chainlink TWAP)
ws.send(JSON.stringify({
action: "subscribe",
subscriptions: [
  { topic: "crypto_prices_twap_thirty", type: "update" },
  { topic: "crypto_prices_twap_sixty",  type: "update" },
],
}));
```

Both streams work without any SDK dependency.

### On the fix itself

The `sideEffects: false` + per-entry-point approach you suggest is the right call. An alternative that might be lower-effort to ship: a **separate published package** (e.g. `@polymarket/perps-client`) that only exports perps data types and the data-fetch/WebSocket helpers, with no CLOB, viem, or auth code in the graph at all. The `@polymarket/client` perps entry could then re-export from it. This lets teams that only need perps data opt into the small package without waiting for the monolith to be restructured.

[cesarenaldi]

One important consideration when connecting directly to the underlying WebSocket APIs is that each service has its own protocol and lifecycle nuances. A correct integration involves more than opening the socket and parsing messages.

The SDK handles service-specific subscriptions, reconnects, resubscriptions, and application-level heartbeats. It also normalizes events across services so their field shapes align with the corresponding REST data, including timestamps, decimals, and other representations.

Integrating directly means taking responsibility for all of those details and may produce behavior inconsistent with the REST client.

[osr21]

Completely agree @cesarenaldi — that caution deserves to be spelled out, because we hit every one of those nuances building the bypass. For anyone tempted by the raw-WS route, here's the actual checklist of what you take on (learned in production):

- **Heartbeats differ per service.** RTDS silently stops delivering after ~10 minutes unless you re-send the subscription (we re-subscribe on a timer); the perps WS has its own ping expectations. Neither is documented — you find out when the feed goes quiet with the socket still "open".
- **Reconnect + resubscribe is on you**, including jittered backoff and replaying the full subscription set — and detecting the gap you just created (the exact problem discussed in #285).
- **Normalization is real work**: raw perps klines arrive as positional arrays (`[ts, o, h, l, c, volume, trades]`), decimals come as strings, timestamps are epoch-ms in some feeds and not others. The SDK's aligned REST/WS shapes are genuinely valuable and easy to underestimate.

So the SDK should absolutely be the default — no disagreement there. The point of the bypass in my comment is that the current packaging *forces* browser consumers into this tradeoff: 3KB of hand-rolled fragility vs 44KB gzip of monolith for a data-only use case. Both options are worse than what a tree-shakable or split package would offer: SDK-grade lifecycle handling at a size proportional to what's used.

Which is why the `@polymarket/react` direction you mentioned is encouraging — if it binds raw action functions on demand, the same per-module packaging could presumably serve non-React browser consumers too (a framework-agnostic core the React package wraps). If the composition layer lands as tree-shakable ESM with `sideEffects: false`, issues like this one and the incentive to bypass both disappear. Happy to re-run the byte-attribution measurement against early builds of that package if useful — it's tooling we already have set up.