drizzle-team / drizzle-kit-mirror

Docs and issues repository for drizzle-kit
287 stars 16 forks source link

[bug] `drizzle-kit push` fails on local sqlite3 attempt due to presence of @libsql/client package #399

Open greg-hammond opened 1 month ago

greg-hammond commented 1 month ago

Attempting to run drizzle-kit push on a local sqlite3 db fails... because my project also has @libsql/client installed.

I have both better-sqlite3 and @libsql/client packages installed... as I want to be able to run dev locally or remotely... as well as push locally or remotely. I have different npm scripts that set up a DB_ENV variable to control how the config operates (see config file below).

Inspecting the code in the connectToSQLite function - it will attempt to create a libsql client based on the presence of the @libsql/client package... and so my url field ends up being treated as a real url, rather than my local db location path, and so parseUri fails with LibsqlError: URL_INVALID: The URL is not in a valid format.

In this case, it seems that checking for the presence of a specific library being installed is a somewhat poor proxy for deciding what to do. Would it be better to drive things more directly from config settings, rather than by checking which package(s) are installed?

versions:

"drizzle-kit": "^0.21.1",
"drizzle-orm": "^0.30.10",

My drizzle.config.ts:

import type { Config } from 'drizzle-kit'
import dotenv from 'dotenv'

dotenv.config()

const remoteDB = process.env.DB_ENV === 'remote'

const config: Config = {
    schema: './src/db/schema/*',
    out: './drizzle/migrations',
    dialect: 'sqlite',
    ...(remoteDB ? { driver: 'turso' } : {}),
    ...(remoteDB
        ? {
                dbCredentials: {
                    url: process.env.DB_URL!,
                    authToken: process.env.DB_AUTH,
                },
            }
        : { dbCredentials: { url: './src/db/dev.db' } }),
    verbose: true,
    strict: true,
}

export default config
greg-hammond commented 1 month ago

@AlexBlokh this is the same issue as #422.

The TLDR is that logic in connectToSQLite gives preference to the presence of @libsql/client over explicit config to the contrary.