@capacms/sdk 1.0.0-next.6 → 1.0.0-next.7

package/CHANGELOG.md

@@ -2,6 +2,28 @@
 
 ## Unreleased
 
+- 1.0.0-next.7. Browsers: the `/api/` and legacy clients called the platform `fetch` as a
+  method of their config, which a browser refuses ("Failed to execute 'fetch'
+  on 'Window': Illegal invocation"), so every read from a browser failed unless
+  `fetch` was passed in. The default fetch is now called through `globalThis`
+  on each request, which also picks up a fetch a framework patches in later.
+- `next` is no longer a peer dependency. No range matches every Next canary,
+  so a site on `next@16.3.0-canary.39` could not `npm install` the SDK without
+  `--legacy-peer-deps`. `@capacms/sdk/nextjs/overlay` still imports `next`,
+  which only a Next site loads.
+- Docs: the edit mark is dropped wherever an entry is serialized to the
+  browser (Pages Router props, SvelteKit and Remix loaders, Nuxt payload);
+  pass the edit flag to `capaAttrs` there. Found testing preview on nine stacks.
+- Next.js: a GraphQL read that gives neither `tags` nor `revalidate`, through
+  `getCapaClient().graphql()`, its builder or `graphql()`, is no longer kept
+  in Next's data cache. It is sent as `entries.list` and `entries.get` send
+  theirs, with no `cache` and no `next`, so a publish shows on the next render
+  whether the page reads by REST or by GraphQL. It used to be kept under
+  `capa:graphql` until a webhook revalidated it, so a site with no webhook
+  route kept serving the old answer by GraphQL while REST showed the new one.
+  A read that gives `tags` or a `revalidate` is kept as before. To keep a read
+  with no tags as it was kept, pass `revalidate: false`, which keeps it under
+  `capa:graphql` until the next publish. `tags: []` now counts as no tags.
 - 1.0.0-next.6. GraphQL, on `@capacms/sdk/next` and `@capacms/sdk/nextjs`,
   and two commands, `capa-codegen --graphql` and `capa persist`. Additive:
   every call that existed behaves as before. `graphql` is an optional peer

package/README.md

@@ -287,9 +287,10 @@ const capa = await draftClient<CapaQuery>({
 `CapaQuery` types the GraphQL builder on the client it returns, as it does
 for `createClient<CapaQuery>`; `getCapaClient<CapaQuery>` and
 `getPublishedClient<CapaQuery>` take it the same way. Without it each helper
-returns an untyped client. `getCapaClient` also keeps its GraphQL reads in
-Next's data cache, as `graphql()` does, under the `tags` and `revalidate`
-each call gives (see The typed builder).
+returns an untyped client. `getCapaClient` sends its GraphQL reads as it
+sends its REST reads, which Next does not keep, unless a call gives `tags` or
+`revalidate`; then it keeps them in Next's data cache as `graphql()` does
+(see The typed builder).
 
 ## GraphQL
 
@@ -335,8 +336,10 @@ once `capa-codegen --graphql` has read it (see Typed documents). Until then
 the call does not compile, and the error says to run it, so a document edited
 since the last run is never silently untyped.
 
-`graphql()` keeps a published read in Next's data cache, through Next's own
-`unstable_cache`, under the tags you give. `BlogIndexModels` lists the models
+Given `tags` or `revalidate`, `graphql()` keeps a published read in Next's
+data cache, through Next's own `unstable_cache`, under the tags you give.
+Given neither, it keeps nothing: the read is sent as a REST read is, and the
+page shows a publish on its next render. `BlogIndexModels` lists the models
 the query reads, which codegen writes beside its types: `articles`, and
 `authors` for `author { name }`. It changes when the query does, so a model
 the query starts reading is never left out. `tagsFor({ namespace })` makes
@@ -348,16 +351,19 @@ library, its alt text say, changes no entry, so it revalidates `capa:media`
 instead, and every read tagged by its models shows the new text. How long a
 read is kept:
 
-- With no `revalidate`, until one of its tags is revalidated. With the
-  webhook route, that is until the next publish of a model it reads.
+- With neither `tags` nor `revalidate`, not at all: every render reads the
+  API, as `entries.list` does, so a site with no webhook route still shows a
+  publish on the next request.
+- With `tags` and no `revalidate`, until one of its tags is revalidated.
+  With the webhook route, that is until the next publish of a model it reads.
 - With `revalidate: 60`, also at most 60 seconds, so a missed webhook costs
-  a minute of stale content at most. This is the only thing it adds.
-- With `revalidate: 0`, not at all: every render reads the API.
+  a minute of stale content at most.
+- With `revalidate: 0`, not at all.
 
-A read with no `tags` is tagged `capa:graphql` (`GRAPHQL_TAG`), which
-`revalidateFromWebhook` revalidates on every content change, so it is never
-stale after a publish; tag it with its models to refresh the page only when
-one of them changes.
+A read with a `revalidate` and no `tags` is tagged `capa:graphql`
+(`GRAPHQL_TAG`), which `revalidateFromWebhook` revalidates on every content
+change, so it is never stale after a publish; tag it with its models to
+refresh the page only when one of them changes.
 
 A read that answered with `errors` is never kept: a root field that timed
 out is shown once and read again on the next request. Next's fetch cache is
@@ -513,10 +519,10 @@ it is never cached. The admin host serves GraphQL by POST only and answers a
 GET as a path it does not serve; a read that did not ask for GET is then
 repeated as a POST, and that host is read by POST for five minutes. A
 `method: "GET"` read there throws "This Capa host does not serve GraphQL by
-GET." In Next.js, `graphql()` from `/nextjs` adds Next's data cache on top,
-for a published read with no errors, a POST included: kept under its `tags`
-until one is revalidated, or for `revalidate` seconds when you give it, and
-never for a draft.
+GET." In Next.js, `graphql()` from `/nextjs` adds Next's data cache on top
+when a read gives `tags` or `revalidate`, for a published read with no
+errors, a POST included: kept under its `tags` until one is revalidated, or
+for `revalidate` seconds when you give it, and never for a draft.
 
 ### The typed builder
 
@@ -557,8 +563,8 @@ document is printed when it runs, so `capa persist` never stored it, and it
 is already a GET that the API and the CDN cache. To persist a read, write it
 as a `#graphql` literal (see Persisted queries).
 
-In a Next.js server component, read through `getCapaClient`. Its reads are
-kept in Next's data cache, under the tags each call names:
+In a Next.js server component, read through `getCapaClient`. A read that
+names tags is kept in Next's data cache under them:
 
 ```tsx
 // app/blog/page.tsx
@@ -579,7 +585,8 @@ export default async function Blog() {
 `tags` and `revalidate` work as they do for `graphql()` (see In a Next.js
 server component). A read is kept until a publish of a model its tags name,
 a read with errors is never kept, and a draft or an edit-mode page is read
-uncached. `capa.graphql(document)` on the same client takes them too.
+uncached. A read with neither is not kept, as the client's REST reads are
+not. `capa.graphql(document)` on the same client takes them too.
 
 Read one field twice in one request with an alias: any other key, with
 `__aliasFor` naming the field it reads. A home page's featured and latest
@@ -1282,7 +1289,8 @@ import { createPreviewRoute } from "@capacms/sdk/nextjs";
 export const GET = createPreviewRoute({ draftMode, redirect });
 
 // in a page: getCapaClient({ draftMode, headers }), then <h1 {...fieldAttrs(post).title}>
-// in the root layout, in edit mode: <CapaOverlay adminOrigins={[...]} /> from @capacms/sdk/nextjs/overlay
+// in the root layout: const edit = await editMode({ draftMode, headers }) from @capacms/sdk/nextjs,
+// then {edit ? <CapaOverlay adminOrigins={[...]} /> : null} from @capacms/sdk/nextjs/overlay
 ```
 
 In Capa, set the project's preview URL to your site, and editors can click
@@ -1330,6 +1338,24 @@ The mark does not survive a spread copy or being passed to a client component,
 so tag in the server component that read the entry. `capaAttrs(entry, field,
 true)` still forces the tags on and `false` forces them off.
 
+**When the entry crosses to the browser as data, pass the flag.** The mark is
+a hidden symbol, so anything that serializes the entry drops it silently: the
+Next Pages Router's `getServerSideProps`, SvelteKit and Remix loaders, Nuxt's
+payload, or your own JSON endpoint. The page then shows the draft with no
+`data-capa-` tags, and the editor has nothing to point at. Nothing errors. Send
+the draft or edit state alongside the entry and hand it to `capaAttrs`:
+
+```tsx
+// getServerSideProps, a +page.server.ts load, useAsyncData on the server...
+return { props: { entry, edit: draft } };
+
+// in the component
+<h1 {...capaAttrs(entry, "title", edit)}>{entry.fields.title}</h1>
+```
+
+Or re-mark the entries where they arrive with `markEditEntries(data)` when the
+page is in edit mode. Tested on the Pages Router, SvelteKit and Nuxt.
+
 GraphQL reads are marked the same way, from `getCapaClient`, an edit-mode
 `createClient` or `graphql()` given `{ draftMode, headers }`. A node is an
 entry when it selected `id` and `model`, and `field` is the field as you

package/dist/config.d.ts

@@ -1,38 +1,3 @@
-/**
- * Client configuration, and the one thing about it that is not obvious.
- *
- * PREVIEW IS A KEY, NOT A FLAG
- * Capa gates unpublished content on the API key's `environment` column, not on
- * anything in the request:
- *
- *     // apps/api/src/routes/v2/api.ts:203
- *     const environment = req.apiKeyEnvironment || "production";
- *     const includeDrafted = environment === "production" ? false : true;
- *
- * So there is no `?preview=true` to pass, and `getContent(ns, id, {preview})`
- * CANNOT be implemented against a published key — the server would ignore it.
- * The honest surface is one client per key:
- *
- *     const capa    = createClient({ ...cfg, apiKey: PUBLISHED_KEY })
- *     const preview = createClient({ ...cfg, apiKey: PREVIEW_KEY })
- *
- * Note also that the comparison above is exact and case-sensitive against a
- * free-text column, so ANY environment that is not literally "production"
- * returns drafts — `staging`, `development`, `draft`, and equally a typo like
- * "Production".
- *
- * AND A CLIENT CANNOT FIND OUT WHICH IT HAS.
- * There is deliberately no `includesDrafts()` here, because it cannot be
- * implemented: `apiKeyEnvironment` is set in verifyApiKey.ts:57, consumed
- * internally to compute `includeDrafted`, and returned to the caller by NO
- * endpoint. /v2/schema carries only {models, relations, checksum, generatedAt}.
- *
- * So a site handed a `draft`, `staging` or `development` key serves unpublished
- * content to the public, and has no way to detect it — not at startup, not at
- * runtime, not from any response. In production-shaped data 29 of 74 keys are
- * non-production. Whatever this SDK offers, it cannot make that safe; the fix
- * is for Capa to report the key's environment on a read a client already makes.
- */
 export interface CapaConfig {
     /** Base URL of the Capa API, e.g. https://api.example.com. No trailing slash required. */
     baseUrl: string;

package/dist/config.js

@@ -1,13 +1,59 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.resolveConfig = resolveConfig;
+/**
+ * Client configuration, and the one thing about it that is not obvious.
+ *
+ * PREVIEW IS A KEY, NOT A FLAG
+ * Capa gates unpublished content on the API key's `environment` column, not on
+ * anything in the request:
+ *
+ *     // apps/api/src/routes/v2/api.ts:203
+ *     const environment = req.apiKeyEnvironment || "production";
+ *     const includeDrafted = environment === "production" ? false : true;
+ *
+ * So there is no `?preview=true` to pass, and `getContent(ns, id, {preview})`
+ * CANNOT be implemented against a published key — the server would ignore it.
+ * The honest surface is one client per key:
+ *
+ *     const capa    = createClient({ ...cfg, apiKey: PUBLISHED_KEY })
+ *     const preview = createClient({ ...cfg, apiKey: PREVIEW_KEY })
+ *
+ * Note also that the comparison above is exact and case-sensitive against a
+ * free-text column, so ANY environment that is not literally "production"
+ * returns drafts — `staging`, `development`, `draft`, and equally a typo like
+ * "Production".
+ *
+ * AND A CLIENT CANNOT FIND OUT WHICH IT HAS.
+ * There is deliberately no `includesDrafts()` here, because it cannot be
+ * implemented: `apiKeyEnvironment` is set in verifyApiKey.ts:57, consumed
+ * internally to compute `includeDrafted`, and returned to the caller by NO
+ * endpoint. /v2/schema carries only {models, relations, checksum, generatedAt}.
+ *
+ * So a site handed a `draft`, `staging` or `development` key serves unpublished
+ * content to the public, and has no way to detect it — not at startup, not at
+ * runtime, not from any response. In production-shaped data 29 of 74 keys are
+ * non-production. Whatever this SDK offers, it cannot make that safe; the fix
+ * is for Capa to report the key's environment on a read a client already makes.
+ */
+/**
+ * The platform fetch, called through `globalThis` on every request. Storing
+ * `globalThis.fetch` and calling it as a method of the config object gives it
+ * the wrong `this`, and a browser refuses that ("Illegal invocation"). Looking
+ * it up per call also picks up a fetch a framework patches in later.
+ */
+function defaultFetch() {
+    if (typeof globalThis.fetch !== "function")
+        return undefined;
+    return ((input, init) => globalThis.fetch(input, init));
+}
 function resolveConfig(config) {
     const missing = ["baseUrl", "apiKey", "tenantId"].filter((k) => !config[k]);
     if (missing.length) {
         throw new Error(`@capacms/sdk: missing ${missing.join(", ")}. ` +
             `createClient needs baseUrl, apiKey and tenantId.`);
     }
-    const fetchImpl = config.fetch ?? globalThis.fetch;
+    const fetchImpl = config.fetch ?? defaultFetch();
     if (typeof fetchImpl !== "function") {
         throw new Error("@capacms/sdk: no fetch available. Pass one via config.fetch on older runtimes.");
     }

package/dist/next/client.d.ts

@@ -387,8 +387,9 @@ export type BuilderCallOptions<O extends GraphQLCallOptions = GraphQLCallOptions
 /**
  * `client.graphql` over one way of reading a document: called with a
  * document, and `query()` printing a selection's document for it. `createClient`
- * reads straight from the API, and `getCapaClient` from `/nextjs` through
- * Next's data cache, with the same refusals.
+ * reads straight from the API, and `getCapaClient` from `/nextjs` the same way
+ * unless a call gives `tags` or `revalidate`, then through Next's data cache,
+ * with the same refusals.
  */
 export declare function graphqlClient<Q, O extends GraphQLCallOptions>(read: (document: string, variables: Record<string, unknown> | undefined, options: O | undefined) => Promise<GraphQLResult<unknown>>): GraphQLClient<Q, O>;
 export interface CapaNextClient<Q = UntypedQuery, O extends GraphQLCallOptions = GraphQLCallOptions> {

package/dist/next/client.js

@@ -18,6 +18,19 @@ const typed_1 = require("./graphql/typed");
 var errors_2 = require("./errors");
 Object.defineProperty(exports, "CapaError", { enumerable: true, get: function () { return errors_2.CapaError; } });
 Object.defineProperty(exports, "isCapaError", { enumerable: true, get: function () { return errors_2.isCapaError; } });
+/**
+ * The platform fetch, called through `globalThis` on every request. Storing
+ * `globalThis.fetch` and calling it as a method of the config object gives it
+ * the wrong `this`, and a browser refuses that ("Failed to execute 'fetch' on
+ * 'Window': Illegal invocation"); Node does not care, which is why only
+ * browser reads broke. Looking it up per call also picks up a fetch a
+ * framework patches in after the client is built (Next does).
+ */
+function defaultFetch() {
+    if (typeof globalThis.fetch !== "function")
+        return undefined;
+    return ((input, init) => globalThis.fetch(input, init));
+}
 /**
  * What a `Capa-Schema` value may look like: hex, 8 to 64 characters.
  *
@@ -35,8 +48,9 @@ const BUILDER_NOT_PERSISTED = "@capacms/sdk/next: graphql.query() cannot send pe
 /**
  * `client.graphql` over one way of reading a document: called with a
  * document, and `query()` printing a selection's document for it. `createClient`
- * reads straight from the API, and `getCapaClient` from `/nextjs` through
- * Next's data cache, with the same refusals.
+ * reads straight from the API, and `getCapaClient` from `/nextjs` the same way
+ * unless a call gives `tags` or `revalidate`, then through Next's data cache,
+ * with the same refusals.
  */
 function graphqlClient(read) {
     const query = async (selection, options) => {
@@ -61,7 +75,7 @@ function resolveNextConfig(config) {
     if (value.contract !== undefined && value.contract !== 1) {
         throw new Error("@capacms/sdk/next: contract must be 1 when provided.");
     }
-    const fetchImpl = value.fetch ?? globalThis.fetch;
+    const fetchImpl = value.fetch ?? defaultFetch();
     if (typeof fetchImpl !== "function") {
         throw new Error("@capacms/sdk/next: no fetch available. Pass one via config.fetch.");
     }

package/dist/nextjs/index.d.ts

@@ -13,11 +13,12 @@ export declare function withCache(fetchImpl: typeof fetch, options: CacheOptions
  */
 export declare function modelTag(namespace: string): string;
 /**
- * The tag `graphql()` gives a read that names no `tags`, and that
- * `revalidateFromWebhook` revalidates on every content change: such a page is
- * never stale after a publish, at the price of refreshing on any publish.
- * Name the models it reads with `tagsFor({ namespace })` to refresh it only
- * when one of those changes.
+ * The tag `graphql()` keeps a read under when it gives a `revalidate` and no
+ * `tags`, and that `revalidateFromWebhook` revalidates on every content
+ * change: such a page is never stale after a publish, at the price of
+ * refreshing on any publish. Name the models it reads with
+ * `tagsFor({ namespace })` to refresh it only when one of those changes. A
+ * read with neither `tags` nor `revalidate` is not kept at all.
  */
 export declare const GRAPHQL_TAG = "capa:graphql";
 /**
@@ -219,10 +220,12 @@ export declare function getPublishedClient<Q = UntypedQuery>(overrides?: Partial
  * `CapaQuery` (from `capa-codegen --graphql`) types the builder, as with
  * `createClient`; leave it out for an untyped client. `config` wins over env.
  *
- * Its GraphQL reads, a document or the builder, are kept in Next's data cache
- * exactly as `graphql()` keeps them, each under the `tags` and `revalidate`
- * it is called with: a published read with no errors, never a draft or an
- * edit-mode page. Its REST reads are sent as `createClient` sends them.
+ * Its REST reads are sent as `createClient` sends them, which Next does not
+ * keep. Its GraphQL reads, a document or the builder, are sent the same way
+ * unless a call gives `tags` or `revalidate`, so a publish shows up on both
+ * alike. Given either, a read is kept in Next's data cache exactly as
+ * `graphql()` keeps it: a published read with no errors, never a draft or an
+ * edit-mode page.
  */
 export declare function getCapaClient<Q = UntypedQuery>(input: {
     draftMode: DraftModeFn;
@@ -234,14 +237,16 @@ export declare function getCapaClient<Q = UntypedQuery>(input: {
 /** Where a GraphQL read in Next keeps its answer: Next's data cache, as `graphql()` and `getCapaClient` keep it. */
 export interface NextCacheOptions extends GraphQLCallOptions {
     /**
-     * Next.js cache tags for this read. `tagsFor({ namespace: <Name>Models })`,
-     * with the list `capa-codegen --graphql` writes beside each document, tags
-     * it with every model the query reads, which `revalidateFromWebhook`
-     * revalidates on a publish. Without tags the read is tagged `GRAPHQL_TAG`,
-     * which every publish revalidates.
+     * Next.js cache tags to keep this read under. `tagsFor({ namespace:
+     * <Name>Models })`, with the list `capa-codegen --graphql` writes beside
+     * each document, tags it with every model the query reads, which
+     * `revalidateFromWebhook` revalidates on a publish. Given a `revalidate`
+     * and no tags, the read is kept under `GRAPHQL_TAG`, which every publish
+     * revalidates. Given neither, the read is not kept: it is sent as a REST
+     * read is, on every render.
      */
     tags?: string[];
-    /** Seconds to cache, or `false` to cache until a tag is revalidated. */
+    /** Seconds to cache, `false` to cache until a tag is revalidated, or 0 not to cache. */
     revalidate?: number | false;
 }
 export interface NextGraphQLOptions extends NextCacheOptions {
@@ -261,9 +266,10 @@ export interface NextGraphQLOptions extends NextCacheOptions {
     config?: Partial<CapaNextConfig>;
     /**
      * Next's `unstable_cache`, from `next/cache`. Leave it out: `graphql()`
-     * loads Next's own. A published read is kept in Next's data cache only when
-     * it answered with no `errors`, under `tags` for `revalidate` seconds, or
-     * with no `revalidate` until one of its tags is revalidated. Next's fetch
+     * loads Next's own. A published read given `tags` or a `revalidate` is kept
+     * in Next's data cache only when it answered with no `errors`, under `tags`
+     * for `revalidate` seconds, or with no `revalidate` until one of its tags is
+     * revalidated. Next's fetch
      * cache is not used for it: that cache keeps any 200, and a GraphQL error
      * is a 200 (a root field that timed out), and in Next 15 it keeps nothing
      * without a `revalidate`, tags or not. Pass it only to supply another.
@@ -293,12 +299,15 @@ export type UnstableCache = <T extends (...args: any[]) => Promise<any>>(cb: T,
  * variables are typed from it, as they are for a `<Name>Document` it writes,
  * and `LatestModels` lists the models it reads.
  *
- * A published read is kept in Next's data cache (`unstable_cache`) when it
- * answered with no errors: under `tags`, for `revalidate` seconds, or with no
- * `revalidate` until `revalidateFromWebhook` revalidates one of its tags on a
- * publish. It goes as a GET, which the CDN and the API also cache for the
- * published key; a document too long for a GET URL goes as a POST, which only
- * Next's data cache keeps. Under draft mode the read uses `CAPA_DRAFT_KEY`, a
+ * With no `tags` and no `revalidate` a read is sent as the REST reads are,
+ * and Next keeps nothing: the page shows a publish on its next render, as a
+ * page reading by REST does. Given either, a published read is kept in Next's
+ * data cache (`unstable_cache`) when it answered with no errors: under `tags`,
+ * for `revalidate` seconds, or with no `revalidate` until
+ * `revalidateFromWebhook` revalidates one of its tags on a publish. It goes
+ * as a GET, which the CDN and the API also cache for the published key; a
+ * document too long for a GET URL goes as a POST, which only Next's data
+ * cache keeps. Under draft mode the read uses `CAPA_DRAFT_KEY`, a
  * `cap_` key, and bypasses the cache (the API answers a development key's GET
  * `no-store`), the same split `getCapaClient` makes for REST, and in edit mode
  * each entry that selects `id` and `model` is marked for `capaAttrs`, uncached.

package/dist/nextjs/index.js

@@ -47,11 +47,12 @@ function modelTag(namespace) {
     return `capa:model:${namespace}`;
 }
 /**
- * The tag `graphql()` gives a read that names no `tags`, and that
- * `revalidateFromWebhook` revalidates on every content change: such a page is
- * never stale after a publish, at the price of refreshing on any publish.
- * Name the models it reads with `tagsFor({ namespace })` to refresh it only
- * when one of those changes.
+ * The tag `graphql()` keeps a read under when it gives a `revalidate` and no
+ * `tags`, and that `revalidateFromWebhook` revalidates on every content
+ * change: such a page is never stale after a publish, at the price of
+ * refreshing on any publish. Name the models it reads with
+ * `tagsFor({ namespace })` to refresh it only when one of those changes. A
+ * read with neither `tags` nor `revalidate` is not kept at all.
  */
 exports.GRAPHQL_TAG = "capa:graphql";
 /**
@@ -423,10 +424,12 @@ function getPublishedClient(overrides = {}) {
  * `CapaQuery` (from `capa-codegen --graphql`) types the builder, as with
  * `createClient`; leave it out for an untyped client. `config` wins over env.
  *
- * Its GraphQL reads, a document or the builder, are kept in Next's data cache
- * exactly as `graphql()` keeps them, each under the `tags` and `revalidate`
- * it is called with: a published read with no errors, never a draft or an
- * edit-mode page. Its REST reads are sent as `createClient` sends them.
+ * Its REST reads are sent as `createClient` sends them, which Next does not
+ * keep. Its GraphQL reads, a document or the builder, are sent the same way
+ * unless a call gives `tags` or `revalidate`, so a publish shows up on both
+ * alike. Given either, a read is kept in Next's data cache exactly as
+ * `graphql()` keeps it: a published read with no errors, never a draft or an
+ * edit-mode page.
  */
 async function getCapaClient(input) {
     const draft = (await input.draftMode()).isEnabled === true;
@@ -493,13 +496,33 @@ async function graphql(document, variables, options = {}) {
     return readInNext(read, document, variables, call, { tags, revalidate });
 }
 /**
- * One GraphQL read in Next, for `graphql()` and `getCapaClient`. Next's data
- * cache holds only a published read with no errors, and the fetch under it is
- * never cached. A draft, an edit-mode read (its entries carry marks a cached
- * copy would lose) and `revalidate: 0` are not cached.
+ * Whether a read said anything about Next's cache: tags to keep it under, or a
+ * `revalidate`. One that said neither is sent as the REST reads are, so a
+ * publish shows up on both the same way.
  */
-async function readInNext(read, document, variables, call, { tags, revalidate }) {
+function namesCaching({ tags, revalidate }) {
+    return (tags !== undefined && tags.length > 0) || revalidate !== undefined;
+}
+/**
+ * One GraphQL read in Next, for `graphql()` and `getCapaClient`.
+ *
+ * With no `tags` and no `revalidate` it is sent exactly as `entries.list` and
+ * `entries.get` send theirs: a plain fetch with no `cache` and no `next`, which
+ * Next does not keep, so the page shows a publish on its next render whether
+ * it reads by REST or by GraphQL. Given `tags` or a `revalidate`, Next's data
+ * cache holds a published read with no errors, and the fetch under it is never
+ * cached. A draft, an edit-mode read (its entries carry marks a cached copy
+ * would lose) and `revalidate: 0` are not cached.
+ */
+async function readInNext(read, document, variables, call, options) {
     const { draft, edit, settings, given } = read;
+    if (!draft && !edit && !namesCaching(options)) {
+        return (0, next_1.createClient)({ editMode: false, ...settings }).graphql(document, variables, call);
+    }
+    // `tags: []` names no tag, so the read is kept under `GRAPHQL_TAG` like one
+    // with no tags: kept under none, nothing could ever revalidate it.
+    const tags = options.tags && options.tags.length > 0 ? options.tags : undefined;
+    const revalidate = options.revalidate;
     const baseFetch = settings.fetch ?? globalThis.fetch;
     const cache = given ?? nextUnstableCache();
     if (cache && !draft) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@capacms/sdk",
-  "version": "1.0.0-next.6",
+  "version": "1.0.0-next.7",
   "description": "The TypeScript SDK for Capa's content API: REST and GraphQL reads typed from your models, Next.js caching and live preview, and codegen.",
   "license": "UNLICENSED",
   "homepage": "https://docs.capacms.com/api",
@@ -68,16 +68,12 @@
   },
   "peerDependencies": {
     "graphql": "^16.9.0",
-    "next": ">=14",
     "react": ">=18"
   },
   "peerDependenciesMeta": {
     "graphql": {
       "optional": true
     },
-    "next": {
-      "optional": true
-    },
     "react": {
       "optional": true
     }