Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

chore(deps): update npm-non-major-dev-dependencies #294

Merged
merged 1 commit into from
Nov 6, 2024
Merged

chore(deps): update npm-non-major-dev-dependencies #294

merged 1 commit into from
Nov 6, 2024

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Sep 24, 2024 •
edited
Loading

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@biomejs/biome (source) 1.9.1 -> 1.9.4 age adoption passing confidence
@cloudflare/workers-types 4.20240909.0 -> 4.20241106.0 age adoption passing confidence
drizzle-kit (source) 0.24.2 -> 0.28.0 age adoption passing confidence
typescript (source) 5.6.2 -> 5.6.3 age adoption passing confidence
vite (source) 5.4.6 -> 5.4.10 age adoption passing confidence
vitest (source) 2.1.1 -> 2.1.4 age adoption passing confidence
wrangler (source) 3.78.4 -> 3.85.0 age adoption passing confidence

Release Notes

biomejs/biome (@​biomejs/biome)

v1.9.4

Compare Source

Analyzer
Bug fixes
CLI
Enhancements

  • The --summary reporter now reports parsing diagnostics too. Contributed by @​ematipico

  • Improved performance of GritQL queries by roughly 25-30%. Contributed by @​arendjr

Configuration
Bug fixes
  • Fix an issue where the JSON schema marked lint rules options as mandatory. Contributed by @​ematipico
Editors
Formatter
Bug fixes
  • Fix #​4121. Respect line width when printing multiline strings. Contributed by @​ah-yu
JavaScript APIs
Linter
New features
Bug Fixes

  • Biome no longer crashes when it encounters a string that contain a multibyte character (#​4181).

    This fixes a regression introduced in Biome 1.9.3
    The regression affected the following linter rules:

    • nursery/useSortedClasses
    • nursery/useTrimStartEnd
    • style/useTemplate
    • suspicious/noMisleadingCharacterClass

    Contributed by @​Conaclos

  • Fix #​4190, where the rule noMissingVarFunction wrongly reported a variable as missing when used inside a var() function that was a newline. Contributed by @​ematipico

  • Fix #​4041. Now the rule useSortedClasses won't be triggered if className is composed only by inlined variables. Contributed by @​ematipico

  • useImportType and useExportType now report useless inline type qualifiers (#​4178).

    The following fix is now proposed:

    - import type { type A, B } from "";
+ import type { A, B } from "";

- export type { type C, D };
+ export type { C, D };

    Contributed by @​Conaclos

  • useExportType now reports ungrouped export from.

    The following fix is now proposed:

    - export { type A, type B } from "";
+ export type { A, B } from "";

    Contributed by @​Conaclos

  • noVoidTypeReturn now accepts void expressions in return position (#​4173).

    The following code is now accepted:

    function f(): void {
  return void 0;
}

    Contributed by @​Conaclos

  • noUselessFragments now correctly handles fragments containing HTML escapes (e.g.  ) inside expression escapes { ... } (#​4059).

    The following code is no longer reported:

    function Component() {
  return (
    <div key={index}>{line || <>&nbsp;</>}</div>
  )
}

    Contributed by @​fireairforce

  • noUnusedFunctionParameters and noUnusedVariables no longer reports a parameter as unused when another parameter has a constructor type with the same parameter name (#​4227).

    In the following code, the name parameter is no longer reported as unused.

    export class Foo {
  bar(name: string, _class: new (name: string) => any) {
    return name
  }
}

    Contributed by @​Conaclos

  • noUndeclaredDependencies now accepts dependency names with dots. Contributed by @​Conaclos

  • useFilenamingConvention now correctly handles renamed exports (#​4254).

    The rule allows the filename to be named as one of the exports of the module.
    For instance, the file containing the following export can be named Button.

    class Button {}
export { Button }

    The rule now correctly handles the renaming of an export.
    For example, the file containing the following export can only be named Button.
    Previously the rule expected the file to be named A.

    class A {}
export { A as Button }

    Contributed by @​Conaclos

  • useConsistentMemberAccessibility now ignore private class members such as #property (#​4276). Contributed by @​Conaclos

  • noUnknownFunction correctly handles calc-size function (#​4212).

    The following code calc-size is no longer reported as unknown:

    .a { height: calc-size(0px); }

    Contributed by @​fireairforce

  • useNamingConvention now allows configuring conventions for readonly index signatures.

Contributed by @​sepruko

  • noDuplicateCustomProperties now correctly handles custom properties and ignores non-custom properties.
    Previously, the rule incorrectly reported duplicates for all properties, including non-custom ones. Contributed by @​togami2864
Parser
Bug Fixes

  • The CSS parser now accepts more emoji in identifiers (#​3627).

    Browsers accept more emoji than the standard allows.
    Biome now accepts these additional emojis.

    The following code is now correctly parsed:

    p {
  --✨-color: red;
  color: var(--✨-color);
}

    Contributed by @​Conaclos

  • Add support for parsing typescript's resolution-mode in Import Types(#​2115)

    export type Fs = typeof import('fs', { with: { 'resolution-mode': 'import' } });
export type TypeFromRequire =
  import("pkg", { with: { "resolution-mode": "require" } }).TypeFromRequire;
export type TypeFromImport =
  import("pkg", { with: { "resolution-mode": "import" } }).TypeFromImport;

    Contributed by @​fireairforce

v1.9.3

Compare Source

CLI
New features

  • GritQL queries that match functions or methods will now match async functions or methods as well.

    If this is not what you want, you can capture the async keyword (or its absence) in a metavariable and assert its emptiness:

    $async function foo() {} where $async <: .

    Contributed by @​arendjr

Bug fixes

  • Fix #​4077: Grit queries no longer need to match the statement's trailing semicolon. Contributed by @​arendjr

  • Fix #​4102. Now the CLI command lint doesn't exit with an error code when using --write/--fix. Contributed by @​ematipico

Configuration
Bug fixes
  • Fix #​4125, where noLabelWithoutControl options where incorrectly marked as mandatory. Contributed by @​ematipico
Editors
  • Fix a case where CSS files weren't correctly linted using the default configuration. Contributed by @​ematipico
Formatter
Bug fixes

  • Fix #​3924 where GraphQL formatter panics in block comments with empty line. Contributed by @​vohoanglong0107

  • Fix a case where raw values inside url() functions weren't properly trimmed.

    .value {
-  background: url(
-   whitespace-around-string
-  );
+ background: url(whitespace-around-string);
}

    Contributed by @​ematipico

  • Fixed #​4076, where a media query wasn't correctly formatted:

    .class {
-  @&#8203;media (1024px <= width <=1280px) {
+  @&#8203;media (1024px <= width <= 1280px) {
   color: red;
   }
}

    Contributed by @​blaze-d83

JavaScript API
Bug fixes
Linter
New features
Enhancements
Bug fixes
Parser
Bug fixes
  • Forbid undefined as type name for typescript parser. Contributed by @​fireairforce

v1.9.2

Compare Source

CLI
New features
Bug fixes
  • Fix #​3917, where the fixed files were incorrectly computed. Contributed by @​ematipico
  • Fixed an issue that caused GritQL contains queries to report false positives when the matched
    node appeared inside a sibling node. Contributed by @​arendjr
Editors
Bug fixes

  • Fix #​3923. Now the .editorconfig is correctly parsed by the LSP, and the options are correctly applied to files when formatting is triggered.
    Plus, the Biome LSP now watches for any change to the .editorconfig, and updates the formatting settings.

  • Reduced the number of log files generated by the LSP server. Now the maximum number of logs saved on disk is seven. Contributed by @​ematipico

  • Fix the code actions capabilities available in the LSP Biome server. Before, the LSP was using the default capabilities, which resulted in pulling code actions even when they were disabled by the editor.

    This means that the code actions are pulled by the client only when the editor enables quickfix.biome, source.organizeImports.biome and source.fixAll.biome.

    Now, if you enable organizeImports.enabled: true in the biome.json, and then you configure your editor with the following code action source.organizeImports.biome: false, the editor won't sort the imports.

    Contributed by @​ematipico

Linter
New features
Bug fixes
Parser
Bug fixes

  • useStrictMode now reports Script files with some directives, but without the use strict directive. Contributed by @​Conaclos

  • The CSS parser now accepts the characters U+FFDCF and U+FFFD in identifiers. Contributed by @​Conaclos

cloudflare/workerd (@​cloudflare/workers-types)

v4.20241106.0

Compare Source

v4.20241022.0

Compare Source

v4.20241018.0

Compare Source

v4.20241011.0

Compare Source

v4.20241004.0

Compare Source

v4.20240925.0

Compare Source

v4.20240924.0

Compare Source

v4.20240919.0

Compare Source

drizzle-team/drizzle-orm (drizzle-kit)

v0.28.0

Compare Source

Breaking changes

Removed support for filtering by nested relations

Current example won't work in 0.28.0:

const usersWithPosts = await db.query.users.findMany({
  where: (table, { sql }) => (sql`json_array_length(${table.posts}) > 0`),
  with: {
    posts: true,
  },
});

The table object in the where callback won't have fields from with and extras. We removed them to be able to build more efficient relational queries, which improved row reads and performance.

If you have used those fields in the where callback before, there are several workarounds:

  1. Applying those filters manually on the code level after the rows are fetched;
  2. Using the core API.
Added Relational Queries mode config for mysql2 driver

Drizzle relational queries always generate exactly one SQL statement to run on the database and it has certain caveats. To have best in class support for every database out there we've introduced modes.

Drizzle relational queries use lateral joins of subqueries under the hood and for now PlanetScale does not support them.

When using mysql2 driver with regular MySQL database - you should specify mode: "default".
When using mysql2 driver with PlanetScale - you need to specify mode: "planetscale".

import { drizzle } from 'drizzle-orm/mysql2';
import mysql from 'mysql2/promise';
import * as schema from './schema';

const connection = await mysql.createConnection({
  uri: process.env.PLANETSCALE_DATABASE_URL,
});

const db = drizzle(connection, { schema, mode: 'planetscale' });

Improved IntelliSense performance for large schemas

We've run the diagnostics on a database schema with 85 tables, 666 columns, 26 enums, 172 indexes and 133 foreign keys. We've optimized internal types which resulted in 430% speed up in IntelliSense.

Improved Relational Queries Permormance and Read Usage

In this release we've fully changed a way query is generated for Relational Queri API.

As a summary we've made current set of changes in query generation startegy:

  1. Lateral Joins: In the new version we're utilizing lateral joins, denoted by the "LEFT JOIN LATERAL" clauses, to retrieve specific data from related tables efficiently For MySQL in PlanetScale and SQLite, we've used simple subquery selects, which improved a query plan and overall performance

  2. Selective Data Retrieval: In the new version we're retrieving only the necessary data from tables. This targeted data retrieval reduces the amount of unnecessary information fetched, resulting in a smaller dataset to process and faster execution.

  3. Reduced Aggregations: In the new version we've reduced the number of aggregation functions (e.g., COUNT, json_agg). By using json_build_array directly within the lateral joins, drizzle is aggregating the data in a more streamlined manner, leading to improved query performance.

  4. Simplified Grouping: In the new version the GROUP BY clause is removed, as the lateral joins and subqueries already handle data aggregation more efficiently.

For this drizzle query

const items = await db.query.comments.findMany({
  limit,
  orderBy: comments.id,
  with: {
    user: {
      columns: { name: true },
    },
    post: {
      columns: { title: true },
      with: {
        user: {
          columns: { name: true },
        },
      },
    },
  },
});

Query that Drizzle generates now

select "comments"."id",
       "comments"."user_id",
       "comments"."post_id",
       "comments"."content",
       "comments_user"."data" as "user",
       "comments_post"."data" as "post"
from "comments"
         left join lateral (select json_build_array("comments_user"."name") as "data"
                            from (select *
                                  from "users" "comments_user"
                                  where "comments_user"."id" = "comments"."user_id"
                                  limit 1) "comments_user") "comments_user" on true
         left join lateral (select json_build_array("comments_post"."title", "comments_post_user"."data") as "data"
                            from (select *
                                  from "posts" "comments_post"
                                  where "comments_post"."id" = "comments"."post_id"
                                  limit 1) "comments_post"
                                     left join lateral (select json_build_array("comments_post_user"."name") as "data"
                                                        from (select *
                                                              from "users" "comments_post_user"
                                                              where "comments_post_user"."id" = "comments_post"."user_id"
                                                              limit 1) "comments_post_user") "comments_post_user"
                                               on true) "comments_post" on true
order by "comments"."id"
limit 1

Query generated before:

SELECT "id",
       "user_id",
       "post_id",
       "content",
       "user"::JSON,
       "post"::JSON
FROM
  (SELECT "comments".*,
          CASE
              WHEN count("comments_post"."id") = 0 THEN '[]'
              ELSE json_agg(json_build_array("comments_post"."title", "comments_post"."user"::JSON))::text
          END AS "post"
   FROM
     (SELECT "comments".*,
             CASE
                 WHEN count("comments_user"."id") = 0 THEN '[]'
                 ELSE json_agg(json_build_array("comments_user"."name"))::text
             END AS "user"
      FROM "comments"
      LEFT JOIN
        (SELECT "comments_user".*
         FROM "users" "comments_user") "comments_user" ON "comments"."user_id" = "comments_user"."id"
      GROUP BY "comments"."id",
               "comments"."user_id",
               "comments"."post_id",
               "comments"."content") "comments"
   LEFT JOIN
     (SELECT "comments_post".*
      FROM
        (SELECT "comments_post".*,
                CASE
                    WHEN count("comments_post_user"."id") = 0 THEN '[]'
                    ELSE json_agg(json_build_array("comments_post_user"."name"))
                END AS "user"
         FROM "posts" "comments_post"
         LEFT JOIN
           (SELECT "comments_post_user".*
            FROM "users" "comments_post_user") "comments_post_user" ON "comments_post"."user_id" = "comments_post_user"."id"
         GROUP BY "comments_post"."id") "comments_post") "comments_post" ON "comments"."post_id" = "comments_post"."id"
   GROUP BY "comments"."id",
            "comments"."user_id",
            "comments"."post_id",
            "comments"."content",
            "comments"."user") "comments"
LIMIT 1

Possibility to insert rows with default values for all columns

You can now provide an empty object or an array of empty objects, and Drizzle will insert all defaults into the database.

// Insert 1 row with all defaults
await db.insert(usersTable).values({});

// Insert 2 rows with all defaults
await db.insert(usersTable).values([{}, {}]);

v0.27.2

Compare Source

🎉 Added support for UNIQUE constraints in PostgreSQL, MySQL, SQLite

For PostgreSQL, unique constraints can be defined at the column level for single-column constraints, and in the third parameter for multi-column constraints. In both cases, it will be possible to define a custom name for the constraint. Additionally, PostgreSQL will receive the NULLS NOT DISTINCT option to restrict having more than one NULL value in a table. Reference

Examples that just shows a different unique usage. Please don't search a real usage for those tables

// single column
const table = pgTable('table', {
  id: serial('id').primaryKey(),
  name: text('name').notNull().unique(),
  state: char('state', { length: 2 }).unique('custom'),
  field: char('field', { length: 2 }).unique('custom_field', { nulls: 'not distinct' }),
});
// multiple columns
const table = pgTable('table', {
  id: serial('id').primaryKey(),
  name: text('name').notNull(),
  state: char('state', { length: 2 }),
}, (t) => ({
  first: unique('custom_name').on(t.name, t.state).nullsNotDistinct(),
  second: unique('custom_name1').on(t.name, t.state),
}));

For MySQL, everything will be the same except for the NULLS NOT DISTINCT option. It appears that MySQL does not support it

Examples that just shows a different unique usage. Please don't search a real usage for those tables

// single column
const table = mysqlTable('table', {
    id: serial('id').primaryKey(),
    name: text('name').notNull().unique(),
    state: text('state').unique('custom'),
    field: text('field').unique('custom_field'),
});
// multiple columns
const table = mysqlTable('cities1', {
    id: serial('id').primaryKey(),
    name: text('name').notNull(),
    state: text('state'),
}, (t) => ({
    first: unique().on(t.name, t.state),
    second: unique('custom_name1').on(t.name, t.state),
}));

In SQLite unique constraints are the same as unique indexes. As long as you can specify a name for the unique index in SQLite - we will treat all unique constraints as unique indexes in internal implementation

// single column
const table = sqliteTable('table', {
    id: int('id').primaryKey(),
    name: text('name').notNull().unique(),
    state: text('state').unique('custom'),
    field: text('field').unique(),
});
// multiple columns
const table = sqliteTable('table', {
    id: int('id').primaryKey(),
    name: text('name').notNull(),
    state: text('state'),
}, (t) => ({
    first: unique().on(t.name, t.state),
    second: unique('custom').on(t.name, t.state),
}));

v0.27.1

Compare Source

import { neon, neonConfig } from '@&#8203;neondatabase/serverless';
import { drizzle } from 'drizzle-orm/neon-http';

neonConfig.fetchConnectionCache = true;

const sql = neon(process.env.DRIZZLE_DATABASE_URL!);
const db = drizzle(sql);

db.select(...)

v0.27.0

Compare Source

Correct behavior when installed in a monorepo (multiple Drizzle instances)

Replacing all instanceof statements with a custom is() function allowed us to handle multiple Drizzle packages interacting properly.

It also fixes one of our biggest Discord tickets: maximum call stack exceeded 🎉

You should now use is() instead of instanceof to check if specific objects are instances of specific Drizzle types. It might be useful if you are building something on top of the Drizzle API.

import { is, Column } from 'drizzle-orm'

if (is(value, Column)) {
  // value's type is narrowed to Column
}

distinct clause support

await db.selectDistinct().from(usersDistinctTable).orderBy(
  usersDistinctTable.id,
  usersDistinctTable.name,
);

Also, distinct on clause is available for PostgreSQL:

await db.selectDistinctOn([usersDistinctTable.id]).from(usersDistinctTable).orderBy(
  usersDistinctTable.id,
);

await db.selectDistinctOn([usersDistinctTable.name], { name: usersDistinctTable.name }).from(
  usersDistinctTable,
).orderBy(usersDistinctTable.name);

bigint and boolean support for SQLite

Contributed by @​MrRahulRamkumar (#​558), @​raducristianpopa (#​411) and @​meech-ward (#​725)

const users = sqliteTable('users', {
  bigintCol: blob('bigint', { mode: 'bigint' }).notNull(),
  boolCol: integer('bool', { mode: 'boolean' }).notNull(),
});

DX improvements

  • Added verbose type error when relational queries are used on a database type without a schema generic
  • Fix where callback in RQB for tables without relations

Various docs improvements

v0.26.2

Compare Source

  • Updated internal versions for the drizzle-kit and drizzle-orm packages. Changes were introduced in the last minor release, and you are required to upgrade both packages to ensure they work as expected

v0.26.1

Compare Source

  • Fix data is malformed for views

v0.26.0

Compare Source

While writing this update, we found one bug that may occur with views in MySQL and SQLite, so please use the drizzle-kit@0.26.1 release

New Features

Checks support in drizzle-kit

You can use drizzle-kit to manage your check constraint defined in drizzle-orm schema definition

For example current drizzle table:

import { sql } from "drizzle-orm";
import { check, pgTable } from "drizzle-orm/pg-core";

export const users = pgTable(
  "users",
  (c) => ({
    id: c.uuid().defaultRandom().primaryKey(),
    username: c.text().notNull(),
    age: c.integer(),
  }),
  (table) => ({
    checkConstraint: check("age_check", sql`${table.age} > 21`),
  })
);

will be generated into

CREATE TABLE IF NOT EXISTS "users" (
  "id" uuid PRIMARY KEY DEFAULT gen_random_uuid() NOT NULL,
  "username" text NOT NULL,
  "age" integer,
  CONSTRAINT "age_check" CHECK ("users"."age" > 21)
);

The same is supported in all dialects

Limitations
  • generate will work as expected for all check constraint changes.
  • push will detect only check renames and will recreate the constraint. All other changes to SQL won't be detected and will be ignored.

So, if you want to change the constraint's SQL definition using only push, you would need to manually comment out the constraint, push, then put it back with the new SQL definition and push one more time.

Views support in drizzle-kit

You can use drizzle-kit to manage your views defined in drizzle-orm schema definition. It will work with all existing dialects and view options

PostgreSQL

For example current drizzle table:

import { sql } from "drizzle-orm";
import {
  check,
  pgMaterializedView,
  pgTable,
  pgView,
} from "drizzle-orm/pg-core";

export const users = pgTable(
  "users",
  (c) => ({
    id: c.uuid().defaultRandom().primaryKey(),
    username: c.text().notNull(),
    age: c.integer(),
  }),
  (table) => ({
    checkConstraint: check("age_check", sql`${table.age} > 21`),
  })
);

export const simpleView = pgView("simple_users_view").as((qb) =>
  qb.select().from(users)
);

export const materializedView = pgMaterializedView(
  "materialized_users_view"
).as((qb) => qb.select().from(users));

will be generated into

CREATE TABLE IF NOT EXISTS "users" (
  "id" uuid PRIMARY KEY DEFAULT gen_random_uuid() NOT NULL,
  "username" text NOT NULL,
  "age" integer,
  CONSTRAINT "age_check" CHECK ("users"."age" > 21)
);

CREATE VIEW "public"."simple_users_view" AS (select "id", "username", "age" from "users");

CREATE MATERIALIZED VIEW "public"."materialized_users_view" AS (select "id", "username", "age" from "users");

Views supported in all dialects, but materialized views are supported only in PostgreSQL

Limitations
  • generate will work as expected for all view changes
  • push limitations:
  1. If you want to change the view's SQL definition using only push, you would need to manually comment out the view, push, then put it back with the new SQL definition and push one more time.

Updates for PostgreSQL enums behavior

We've updated enum behavior in Drizzle with PostgreSQL:

  • Add value after or before in enum: With this change, Drizzle will now respect the order of values in the enum and allow adding new values after or before a specific one.

  • Support for dropping a value from an enum: In this case, Drizzle will attempt to alter all columns using the enum to text, then drop the existing enum and create a new one with the updated set of values. After that, all columns previously using the enum will be altered back to the new enum.

If the deleted enum value was used by a column, this process will result in a database error.

  • Support for dropping an enum

  • Support for moving enums between schemas

  • Support for renaming enums

v0.25.0

Compare Source

Breaking changes and migrate guide for Turso users

If you are using Turso and libsql, you will need to upgrade your drizzle.config and @libsql/client package.

  1. This version of drizzle-orm will only work with @libsql/client@0.10.0 or higher if you are using the migrate function. For other use cases, you can continue using previous versions(But the suggestion is to upgrade)
    To install the latest version, use the command:
npm i @&#8203;libsql/client@latest
  1. Previously, we had a common drizzle.config for SQLite and Turso users, which allowed a shared strategy for both dialects. Starting with this release, we are introducing the turso dialect in drizzle-kit. We will evolve and improve Turso as a separate dialect with its own migration strategies.

Before

import { defineConfig } from "drizzle-kit";

export default defineConfig({
  dialect: "sqlite",
  schema: "./schema.ts",
  out: "./drizzle",
  dbCredentials: {
    url: "database.db",
  },
  breakpoints: true,
  verbose: true,
  strict: true,
});

After

import { defineConfig } from "drizzle-kit";

export default defineConfig({
  dialect: "turso",
  schema: "./schema.ts",
  out: "./drizzle",
  dbCredentials: {
    url: "database.db",
  },
  breakpoints: true,
  verbose: true,
  strict: true,
});

If you are using only SQLite, you can use dialect: "sqlite"

LibSQL/Turso and Sqlite migration updates

SQLite "generate" and "push" statements updates

Starting from this release, we will no longer generate comments like this:

      '/*\n SQLite does not support "Changing existing column type" out of the box, we do not generate automatic migration for that, so it has to be done manually'
      + '\n Please refer to: https://www.techonthenet.com/sqlite/tables/alter_table.php'
      + '\n                  https://www.sqlite.org/lang_altertable.html'
      + '\n                  https://stackoverflow.com/questions/2083543/modify-a-columns-type-in-sqlite3'
      + "\n\n Due to that we don't generate migration automatically and it has to be done manually"
      + '\n*/'

We will generate a set of statements, and you can decide if it's appropriate to create data-moving statements instead. Here is an example of the SQL file you'll receive now:

PRAGMA foreign_keys=OFF;
--> statement-breakpoint
CREATE TABLE `__new_worker` (
  `id` integer PRIMARY KEY NOT NULL,
  `name` text NOT NULL,
  `salary` text NOT NULL,
  `job_id` integer,
  FOREIGN KEY (`job_id`) REFERENCES `job`(`id`) ON UPDATE no action ON DELETE no action
);
--> statement-breakpoint
INSERT INTO `__new_worker`("id", "name", "salary", "job_id") SELECT "id", "name", "salary", "job_id" FROM `worker`;
--> statement-breakpoint
DROP TABLE `worker`;
--> statement-breakpoint
ALTER TABLE `__new_worker` RENAME TO `worker`;
--> statement-breakpoint
PRAGMA foreign_keys=ON;
LibSQL/Turso "generate" and "push" statements updates

Since LibSQL supports more ALTER statements than SQLite, we can generate more statements without recreating your schema and moving all the data, which can be potentially dangerous for production environments.

LibSQL and Turso will now have a separate dialect in the Drizzle config file, meaning that we will evolve Turso and LibSQL independently from SQLite and will aim to support as many features as Turso/LibSQL offer.

With the updated LibSQL migration strategy, you will have the ability to:

  • Change Data Type: Set a new data type for existing columns.
  • Set and Drop Default Values: Add or remove default values for existing columns.
  • Set and Drop NOT NULL: Add or remove the NOT NULL constraint on existing columns.
  • Add References to Existing Columns: Add foreign key references to existing columns

You can find more information in the LibSQL documentation

LIMITATIONS
  • Dropping foreign key will cause table recreation.

This is because LibSQL/Turso does not support dropping this type of foreign key.

CREATE TABLE `users` (
  `id` integer NOT NULL,
  `name` integer,
  `age` integer PRIMARY KEY NOT NULL
  FOREIGN KEY (`name`) REFERENCES `users1`("id") ON UPDATE no action ON DELETE no action
);

  • If the table has indexes, altering columns will cause index recreation:
    Drizzle-Kit will drop the indexes, modify the columns, and then create the indexes.

  • Adding or dropping composite foreign keys is not supported and will cause table recreation.

  • Primary key columns can not be altered and will cause table recreation.

  • Altering columns that are part of foreign key will cause table recreation.

NOTES
  • You can create a reference on any column type, but if you want to insert values, the referenced column must have a unique index or primary key.
CREATE TABLE parent(a PRIMARY KEY, b UNIQUE, c, d, e, f);
CREATE UNIQUE INDEX i1 ON parent(c, d);
CREATE INDEX i2 ON parent(e);
CREATE UNIQUE INDEX i3 ON parent(f COLLATE nocase);

CREATE TABLE child1(f, g REFERENCES parent(a));                        -- Ok
CREATE TABLE child2(h, i REFERENCES parent(b));                        -- Ok
CREATE TABLE child3(j, k, FOREIGN KEY(j, k) REFERENCES parent(c, d));  -- Ok
CREATE TABLE child4(l, m REFERENCES parent(e));                        -- Error!
CREATE TABLE child5(n, o REFERENCES parent(f));                        -- Error!
CREATE TABLE child6(p, q, FOREIGN KEY(p, q) REFERENCES parent(b, c));  -- Error!
CREATE TABLE child7(r REFERENCES parent(c));                           -- Error!

NOTE: The foreign key for the table child5 is an error because, although the parent key column has a unique index, the index uses a different collating sequence.

See more: https://www.sqlite.org/foreignkeys.html

New casing param in drizzle-orm and drizzle-kit

There are more improvements you can make to your schema definition. The most common way to name your variables in a database and in TypeScript code is usually snake_case in the database and camelCase in the code. For this case, in Drizzle, you can now define a naming strategy in your database to help Drizzle map column keys automatically. Let's take a table from the previous example and make it work with the new casing API in Drizzle

Table can now become:

import { pgTable } from "drizzle-orm/pg-core";

export const ingredients = pgTable("ingredients", (t) => ({
  id: t.uuid().defaultRandom().primaryKey(),
  name: t.text().notNull(),
  description: t.text(),
  inStock: t.boolean().default(true),
}));

As you can see, inStock doesn't have a database name alias, but by defining the casing configuration at the connection level, all queries will automatically map it to snake_case

const db = await drizzle('node-postgres', { connection: '', casing: 'snake_case' })

For drizzle-kit migrations generation you should also specify casing param in drizzle config, so you can be sure you casing strategy will be applied to drizzle-kit as well

import { defineConfig } from "drizzle-kit";

export default defineConfig({
  dialect: "postgresql",
  schema: "./schema.ts",
  dbCredentials: {
    url: "postgresql://postgres:password@localhost:5432/db",
  },
  casing: "snake_case",
});
microsoft/TypeScript (typescript)

v5.6.3

Compare Source

vitejs/vite (vite)

v5.4.10

Compare Source

Please refer to CHANGELOG.md for details.

v5.4.9

Compare Source

Please refer to CHANGELOG.md for details.

v5.4.8

Compare Source

Please refer to CHANGELOG.md for details.

v5.4.7

Compare Source

Please refer to [CHANGELOG.md](https://redirect.github.com/vitejs/vite/blob/v5.4.7/pa

Configuration

📅 Schedule: Branch creation - "on wednesday" in timezone Asia/Tokyo, Automerge - "on friday" in timezone Asia/Tokyo.

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot force-pushed the renovate/npm-non-major-dev-dependencies branch 9 times, most recently from 622f61d to 20218c9 Compare October 1, 2024 19:52
@renovate renovate bot force-pushed the renovate/npm-non-major-dev-dependencies branch 7 times, most recently from de6f459 to c8f4097 Compare October 9, 2024 00:37
@renovate renovate bot force-pushed the renovate/npm-non-major-dev-dependencies branch 8 times, most recently from 39e83a4 to e8fb59f Compare October 17, 2024 19:19
@renovate renovate bot force-pushed the renovate/npm-non-major-dev-dependencies branch 3 times, most recently from 97411e6 to 03da1b4 Compare October 24, 2024 11:27
@renovate renovate bot force-pushed the renovate/npm-non-major-dev-dependencies branch from 03da1b4 to 5bf6f07 Compare October 28, 2024 16:07
@renovate renovate bot force-pushed the renovate/npm-non-major-dev-dependencies branch 4 times, most recently from f15fba3 to ad0c6fc Compare November 1, 2024 18:55
@renovate renovate bot force-pushed the renovate/npm-non-major-dev-dependencies branch 2 times, most recently from 07bb699 to ceeb411 Compare November 6, 2024 19:44
@renovate renovate bot force-pushed the renovate/npm-non-major-dev-dependencies branch from ceeb411 to 8770f91 Compare November 6, 2024 23:25
@renovate renovate bot enabled auto-merge (squash) November 6, 2024 23:25
@renovate renovate bot merged commit 9d7321d into main Nov 6, 2024
1 check failed
@renovate renovate bot deleted the renovate/npm-non-major-dev-dependencies branch November 6, 2024 23:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
dependencies renovate
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants