@bison-lab/payload-core 3.15.0 → 3.16.0

package/README.md

@@ -173,10 +173,7 @@ export default buildConfig({
           mark: { url: "/logo-mark.svg", alt: "Acme mark" },
         },
       },
-      colorUsages: {
-        collections: ["pages"],
-        globals: ["navigation"],
-      },
+      colorUsages: true,
       onPublish: async () => {
         revalidateTag("theme");
       },
@@ -186,13 +183,15 @@ export default buildConfig({
 ```
 
 **Color usages.** `createTheme({ colorUsages })` is the only site wiring for
-"is this custom color assigned?" Name every collection and global that
-stores a `lookField` / `colorTokenField` (or a string token those fields
-wrote). The package scans those documents — drafts included — and
-rewrites tokens when Colors Delete needs a replacement. Omit the option,
-or pass empty arrays, and every additional color is unused and deletes
-immediately. A new look surface is added to `colorUsages`, not copied
-into a site helper. Site adopt names the slugs (SPI-93).
+"is this custom color assigned?" Pass `true` to scan every collection and
+global Payload has registered when Colors Delete runs — drafts included,
+blocks included. Payload internals (`payload-*`) and Theme itself are
+skipped, so the library row being deleted is not treated as a use, and a
+later Navigation or Territories global joins without a site change. A
+`{ collections, globals }` list still names slugs when a site wants a
+narrower walk. Omit the option, or pass empty arrays, and every
+additional color is unused and deletes immediately. The site does not
+copy `findColorTokens`.
 
 Then `payload generate:importmap` (the Theme fields resolve from
 `@bison-lab/payload-core/admin`), `payload generate:types`, and