@_linked/shape-ui 2.3.3 → 2.3.4

package/lib/esm/package.d.ts

@@ -1,3 +1,18 @@
-import { getPackageShape, linkedOntology, linkedShape, linkedUtil, packageExports, registerPackageExport, registerPackageModule } from '@_linked/core/package';
-export declare const packageName: string;
-export { getPackageShape, linkedOntology, linkedShape, linkedUtil, packageExports, registerPackageExport, registerPackageModule, };
+/**
+ * This package's own identity.
+ *
+ * It used to re-export `@_linked/core`'s decorators verbatim, which meant any
+ * shape declared here would register under the package name `@_linked/core`
+ * and carry a `.../shape/core/...` IRI. A third name — a cosmetic
+ * `packageName: '@_linked/ui'` literal — matched neither the npm name nor the
+ * registration.
+ *
+ * Nothing is decorated here today, so nothing was mis-registered. The point is
+ * that the next shape added to this package would have been, silently: a shape
+ * whose IRI names the wrong package is unreachable by `Server.call`, which
+ * routes on exactly that name.
+ */
+export declare const linkedShape: {
+    <T extends typeof import("@_linked/core/shapes/Shape").Shape>(constructor: T): void;
+    <T extends typeof import("@_linked/core/shapes/Shape").Shape>(config?: import("@_linked/core/utils/Package").ShapeConfig): (constructor: T) => void;
+}, linkedUtil: (constructor: any) => any, linkedOntology: (allFileExports: any, nameSpace: (term: string) => import("@_linked/core/utils/NodeReference").NodeReferenceValue, suggestedPrefixAndFileName: string, loadDataFunction?: () => Promise<any>, dataSource?: string | string[]) => void, registerPackageExport: (exportedObject: any) => void, registerPackageModule: (_module: any) => void, getPackageShape: (name: string) => import("@_linked/core/shapes/Shape").ShapeConstructor | undefined, packageExports: any, packageName: string;

package/lib/esm/package.js

@@ -1,4 +1,17 @@
-import { getPackageShape, linkedOntology, linkedShape, linkedUtil, packageExports, registerPackageExport, registerPackageModule, } from '@_linked/core/package';
-export const { packageName } = { packageName: '@_linked/ui' };
-export { getPackageShape, linkedOntology, linkedShape, linkedUtil, packageExports, registerPackageExport, registerPackageModule, };
+import { linkedPackage } from '@_linked/core/utils/Package';
+/**
+ * This package's own identity.
+ *
+ * It used to re-export `@_linked/core`'s decorators verbatim, which meant any
+ * shape declared here would register under the package name `@_linked/core`
+ * and carry a `.../shape/core/...` IRI. A third name — a cosmetic
+ * `packageName: '@_linked/ui'` literal — matched neither the npm name nor the
+ * registration.
+ *
+ * Nothing is decorated here today, so nothing was mis-registered. The point is
+ * that the next shape added to this package would have been, silently: a shape
+ * whose IRI names the wrong package is unreachable by `Server.call`, which
+ * routes on exactly that name.
+ */
+export const { linkedShape, linkedUtil, linkedOntology, registerPackageExport, registerPackageModule, getPackageShape, packageExports, packageName, } = linkedPackage('@_linked/shape-ui');
 //# sourceMappingURL=package.js.map

package/lib/esm/package.js.map

@@ -1 +1 @@
-{"version":3,"file":"package.js","sourceRoot":"","sources":["../../src/package.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,eAAe,EACf,cAAc,EACd,WAAW,EACX,UAAU,EACV,cAAc,EACd,qBAAqB,EACrB,qBAAqB,GACtB,MAAM,uBAAuB,CAAC;AAE/B,MAAM,CAAC,MAAM,EAAE,WAAW,EAAE,GAAG,EAAE,WAAW,EAAE,aAAa,EAAE,CAAC;AAE9D,OAAO,EACL,eAAe,EACf,cAAc,EACd,WAAW,EACX,UAAU,EACV,cAAc,EACd,qBAAqB,EACrB,qBAAqB,GACtB,CAAC"}
+{"version":3,"file":"package.js","sourceRoot":"","sources":["../../src/package.ts"],"names":[],"mappings":"AAAA,OAAO,EAAC,aAAa,EAAC,MAAM,6BAA6B,CAAC;AAE1D;;;;;;;;;;;;;GAaG;AACH,MAAM,CAAC,MAAM,EACX,WAAW,EACX,UAAU,EACV,cAAc,EACd,qBAAqB,EACrB,qBAAqB,EACrB,eAAe,EACf,cAAc,EACd,WAAW,GACZ,GAAG,aAAa,CAAC,mBAAmB,CAAC,CAAC"}

package/package.json

@@ -10,7 +10,7 @@
     "type": "git",
     "url": "git+https://github.com/linked-fw/shape-ui.git"
   },
-  "version": "2.3.3",
+  "version": "2.3.4",
   "packageManager": "npm@11.19.1",
   "type": "module",
   "linkedPackage": true,

package/src/package.ts

@@ -1,21 +1,26 @@
-import {
-  getPackageShape,
-  linkedOntology,
+import {linkedPackage} from '@_linked/core/utils/Package';
+
+/**
+ * This package's own identity.
+ *
+ * It used to re-export `@_linked/core`'s decorators verbatim, which meant any
+ * shape declared here would register under the package name `@_linked/core`
+ * and carry a `.../shape/core/...` IRI. A third name — a cosmetic
+ * `packageName: '@_linked/ui'` literal — matched neither the npm name nor the
+ * registration.
+ *
+ * Nothing is decorated here today, so nothing was mis-registered. The point is
+ * that the next shape added to this package would have been, silently: a shape
+ * whose IRI names the wrong package is unreachable by `Server.call`, which
+ * routes on exactly that name.
+ */
+export const {
   linkedShape,
   linkedUtil,
-  packageExports,
+  linkedOntology,
   registerPackageExport,
   registerPackageModule,
-} from '@_linked/core/package';
-
-export const { packageName } = { packageName: '@_linked/ui' };
-
-export {
   getPackageShape,
-  linkedOntology,
-  linkedShape,
-  linkedUtil,
   packageExports,
-  registerPackageExport,
-  registerPackageModule,
-};
+  packageName,
+} = linkedPackage('@_linked/shape-ui');