turbine-orm 0.64.0 → 0.64.1

package/dist/cjs/query/relations.js

@@ -459,20 +459,17 @@ function orderByEntryFingerprint(qi, d, targetTable) {
     return String(d);
 }
 function buildOrderBy(qi, orderBy, params, lateralSink) {
-    // Dev-only: validate that orderBy fields exist in the table schema. Relation
-    // orderBy keys (object values that are neither a vector nor an OrderBySpec)
-    // are validated in the relation branch below, so skip them here.
-    if (process.env.NODE_ENV !== 'production') {
-        for (const [key, value] of (0, filters_js_1.orderByEntries)(orderBy)) {
-            if (isRelationOrderByValue(qi, value) && (0, utils_js_1.ownLookup)(qi.tableMeta.relations, key))
-                continue;
-            const snakeKey = (0, schema_js_1.camelToSnake)(key);
-            if (!qi.tableMeta.columns.some((c) => c.name === snakeKey) && !Object.hasOwn(qi.tableMeta.columnMap, key)) {
-                console.warn(`[turbine] Unknown orderBy field "${key}" for table "${qi.tableMeta.name}". ` +
-                    'This will cause a runtime error.');
-            }
-        }
-    }
+    // There used to be a dev-only pre-scan here that printed `Unknown orderBy
+    // field "x" for table "y". This will cause a runtime error.` and then let
+    // compilation continue into the code below, which throws for the same key
+    // with a better message (it names the table, suggests the closest column and
+    // lists the valid relations). Every unknown-key shape was measured: plain
+    // direction, OrderBySpec, JSON path, both relation-shaped values, and array
+    // form. All six warn-and-then-throw; none reaches the end of this function.
+    // A warning whose entire content is a prediction of the exception on the next
+    // line is noise in dev logs and a second place to keep the key-resolution
+    // rules in step, so it is gone. See orderby-unknown-field.test.ts, which pins
+    // the refusal itself across that surface.
     const meta = qi.schema.tables[qi.table];
     let relOrdCounter = 0;
     return (0, filters_js_1.orderByEntries)(orderBy)

package/dist/query/relations.js

@@ -381,20 +381,17 @@ export function orderByEntryFingerprint(qi, d, targetTable) {
     return String(d);
 }
 export function buildOrderBy(qi, orderBy, params, lateralSink) {
-    // Dev-only: validate that orderBy fields exist in the table schema. Relation
-    // orderBy keys (object values that are neither a vector nor an OrderBySpec)
-    // are validated in the relation branch below, so skip them here.
-    if (process.env.NODE_ENV !== 'production') {
-        for (const [key, value] of orderByEntries(orderBy)) {
-            if (isRelationOrderByValue(qi, value) && ownLookup(qi.tableMeta.relations, key))
-                continue;
-            const snakeKey = camelToSnake(key);
-            if (!qi.tableMeta.columns.some((c) => c.name === snakeKey) && !Object.hasOwn(qi.tableMeta.columnMap, key)) {
-                console.warn(`[turbine] Unknown orderBy field "${key}" for table "${qi.tableMeta.name}". ` +
-                    'This will cause a runtime error.');
-            }
-        }
-    }
+    // There used to be a dev-only pre-scan here that printed `Unknown orderBy
+    // field "x" for table "y". This will cause a runtime error.` and then let
+    // compilation continue into the code below, which throws for the same key
+    // with a better message (it names the table, suggests the closest column and
+    // lists the valid relations). Every unknown-key shape was measured: plain
+    // direction, OrderBySpec, JSON path, both relation-shaped values, and array
+    // form. All six warn-and-then-throw; none reaches the end of this function.
+    // A warning whose entire content is a prediction of the exception on the next
+    // line is noise in dev logs and a second place to keep the key-resolution
+    // rules in step, so it is gone. See orderby-unknown-field.test.ts, which pins
+    // the refusal itself across that surface.
     const meta = qi.schema.tables[qi.table];
     let relOrdCounter = 0;
     return orderByEntries(orderBy)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "turbine-orm",
-  "version": "0.64.0",
+  "version": "0.64.1",
   "description": "Postgres-native TypeScript ORM, runs on Neon, Vercel Postgres, Cloudflare, Supabase. Streaming cursors, typed errors, single-query nested relations. One dependency, no WASM engine",
   "type": "module",
   "//exports": "Each subpath declares its types PER CONDITION. A single shared top-level \"types\" resolves to the ESM declarations for `require` too, which is TS1479 (\"is an ES module ... cannot be require()d\") for any CJS consumer on moduleResolution node16/nodenext. The require condition points at dist/cjs, which ships its own {\"type\":\"commonjs\"} package.json, so those declarations are CJS declarations. Gated in CI by publint + @arethetypeswrong/cli + a real .cts consumer typecheck (see the package-types job in ci.yml).",