@decocms/apps-vtex 7.8.0 → 7.10.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +7 -5
- package/src/__tests__/schemas.test.ts +71 -0
- package/src/commerceLoaders.ts +6 -0
- package/src/mod.ts +5 -0
- package/src/schemas.gen.ts +3191 -0
- package/src/schemas.ts +30 -0
package/src/schemas.ts
ADDED
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Registers the real props schemas for VTEX loaders/actions into the CMS
|
|
3
|
+
* schema registry, so `GET /deco/meta` publishes full props forms (enums,
|
|
4
|
+
* titles, required) instead of the `__resolveType`-only stubs that
|
|
5
|
+
* registerCommerceLoaders() auto-registers.
|
|
6
|
+
*
|
|
7
|
+
* The schemas come from `schemas.gen.ts`, generated at build time by
|
|
8
|
+
* @decocms/blocks-cli's generate-app-schemas.ts (`bun run generate:schemas`)
|
|
9
|
+
* — Props are TypeScript types, erased at runtime, so extraction cannot
|
|
10
|
+
* happen in the site.
|
|
11
|
+
*
|
|
12
|
+
* Called from every server entrypoint a site can wire VTEX through
|
|
13
|
+
* (createVtexCommerceLoaders, mod.configure). Idempotent; real schemas also
|
|
14
|
+
* take precedence over stubs inside the registry, so call order relative to
|
|
15
|
+
* registerCommerceLoaders() doesn't matter.
|
|
16
|
+
*/
|
|
17
|
+
import { registerAppSchemas } from "@decocms/blocks/cms/client";
|
|
18
|
+
import { actionSchemas, loaderSchemas } from "./schemas.gen";
|
|
19
|
+
|
|
20
|
+
let registered = false;
|
|
21
|
+
|
|
22
|
+
export function registerVtexSchemas(): void {
|
|
23
|
+
if (registered) return;
|
|
24
|
+
registered = true;
|
|
25
|
+
registerAppSchemas({
|
|
26
|
+
namespace: "vtex",
|
|
27
|
+
loaders: loaderSchemas,
|
|
28
|
+
actions: actionSchemas,
|
|
29
|
+
});
|
|
30
|
+
}
|