@saena-io/content 0.1.2 → 0.1.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@saena-io/content",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "type": "module",
   "main": "./src/index.ts",
   "types": "./src/index.ts",

package/src/index.ts

@@ -27,6 +27,10 @@ import {
 // Public-site reads (a page's sections, or a collection's entries) for the host's SSR loaders to call directly —
 // public rendering is SSR in the route loader, not a client RPC.
 export { getPageContent, getSectionContent, getItemBySlug, listItems } from './service';
+// Server-direct writes for scripts (seeding, imports) that hold a privileged RequestContext — symmetric with the
+// reads above. Both enforce `content.manage`; a seed acts as a staff actor. The admin's own edits go through the
+// plugin's RPC server fns (./contract), not these.
+export { saveSection, saveItem } from './service';
 export type { SaveSectionInput, SaveCollectionItemInput, CollectionItemRecord } from './service';
 
 export const contentPlugin = definePlugin({

package/src/singleton.test.ts

@@ -0,0 +1,21 @@
+import { describe, expect, it } from 'vitest';
+import { singletonMap } from './singleton';
+
+// Regression guard for the bug that broke Content in scaffolded apps: when @saena-io/content is consumed as
+// a published dependency, define.ts could load as two module instances, so a plain `new Map()` registry split
+// in two. singletonMap anchors the Map on globalThis, so every instance shares it.
+describe('singletonMap', () => {
+  it('returns the same Map for the same key (shared across callers)', () => {
+    const a = singletonMap<string, number>('content.test.shared');
+    a.set('x', 1);
+    const b = singletonMap<string, number>('content.test.shared');
+    expect(b).toBe(a);
+    expect(b.get('x')).toBe(1);
+  });
+
+  it('returns distinct Maps for different keys', () => {
+    const a = singletonMap('content.test.a');
+    const b = singletonMap('content.test.b');
+    expect(a).not.toBe(b);
+  });
+});