@rwillians/qx 0.1.14 → 0.1.15

package/README.md

@@ -51,34 +51,28 @@ console.log(user);
 Here's the basics of what I need from an ORM, thus it's my priority to
 build it first:
 
-- [ ] Defining model fields should be very similar to defining a
-      schema with [Zod](https://zod.dev) (with support for validation
-      refiements and transformations).
-- [ ] The model should have a schema compatible with
-      [standard schema](https://github.com/standard-schema/standard-schema),
-      meaning it should be interoperable with [Zod](https://zod.dev),
-      [ArkType](https://arktype.io), [Joi](https://joi.dev), etc.
-- [ ] It should have a SQL-Like, type-safe, fluent query builder api
-      that works even for NoSQL databases¹, allowing us to write
-      queries once then use them with any supported database.
-- [ ] The query builder should output a plain map representation of
-      the query that can be encoded to JSON, mostly for three reasons:
+- Defining model fields should be very similar to defining a schema
+  with [Zod](https://zod.dev) (with support for validation refiements
+  and transformations).
+- The model should have a schema compatible with [standard schema](https://github.com/standard-schema/standard-schema),
+  meaning it should be interoperable with [Zod](https://zod.dev),
+  [ArkType](https://arktype.io), [Joi](https://joi.dev), etc.
+- It should have a SQL-Like, type-safe, fluent query builder api that
+  works even for NoSQL databases¹, allowing us to write queries once
+  then use them with any supported database.
+- The query builder should output a plain map representation of the
+  query that can be encoded to JSON, mostly for three reasons:
     1. It's easy to test;
     2. Makes it easier to debug queries; and
     3. Makes `qx` more modular, allowing the community to build
        their own extensions.
-- [ ] The query results should be type-safe.
+- The query results should be type-safe.
 
 _¹ Some database adapters might not support all query features, that's
    expected._
 
 Once this vision is fullfilled, `qx` will become `v1.0.0`.
 
-> [!NOTE]
-> Migrations are not part of the scope yet, sorry.
-> I don't like the way migrations work in most ORMs, so I'll take my
-> time to figure out what coulde be a better way to do it.
-
 
 ## Components
 
@@ -99,7 +93,7 @@ library:
 Database adapters are per driver implementation. Quex ships with a few
 hand picked built-in database adapters:
 
-- [ ] bun-sqlite3 (prioritary)
+- [x] bun-sqlite3 (prioritary)
 - [ ] bun-postgres
 - [ ] mongodb
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@rwillians/qx",
   "description": "A teeny tiny ORM for SQLite.",
-  "version": "0.1.14",
+  "version": "0.1.15",
   "author": "Rafael Willians <me@rwillians.com>",
   "license": "MIT",
   "repository": {
@@ -36,11 +36,11 @@
       "require": "./dist/cjs/bun-sqlite.js",
       "default": "./dist/cjs/bun-sqlite.js"
     },
-    "./pretty-logger": {
-      "types": "./dist/types/pretty-logger.d.ts",
-      "import": "./dist/esm/pretty-logger.js",
-      "require": "./dist/cjs/pretty-logger.js",
-      "default": "./dist/cjs/pretty-logger.js"
+    "./console-logger": {
+      "types": "./dist/types/console-logger.d.ts",
+      "import": "./dist/esm/console-logger.js",
+      "require": "./dist/cjs/console-logger.js",
+      "default": "./dist/cjs/console-logger.js"
     },
     "./experimental-migration": {
       "types": "./dist/types/experimental-migration.d.ts",