Add MSSQL dialect support to @rstore/nuxt-drizzle

[faridguzman91]

Clear and concise description of the problem

Loading the module with an MSSQL-dialect drizzle.config.ts fails at startup. The root cause is a hard-coded dialect switch in module.mjs that has no mssql case. Every mssqlTable schema entry falls through with config === undefined, and the build then errors in a downstream instanceof check.

Observed on:

• @rstore/nuxt-drizzle@0.8.4
• @rstore/nuxt@0.8.4
• drizzle-orm@1.0.0-beta.22
• drizzle-kit@1.0.0-beta.22
• Nuxt 3.21

Representative drizzle.config.ts:

export default defineConfig({
  out: './drizzle',
  schema: './server/db/schema.ts',
  dialect: 'mssql',
  dbCredentials: { url: process.env.NUXT_DATABASE_URL ?? '' },
})

Dev server output:

Pre-transform error: Failed to resolve import "#build/$rstore-drizzle-collections.js"
ERROR  [unhandledRejection] Could not load virtual:$rstore-drizzle-server-utils.js
TypeError: Right-hand side of 'instanceof' is not an object
    at is (drizzle-orm/entity.js:6:12)
    at nuxt-drizzle/dist/module.mjs:128:39

The missing dialect case and the Relations import (see Additional context) are currently the only things standing between rstore and a fairly common enterprise stack: Nuxt + Drizzle + MSSQL (via msnodesqlv8 / mssql).

Suggested solution

1. Add an mssql case to the dialect switch

In packages/nuxt-drizzle/src/module.ts (shipped as module.mjs), the switch around line 99 that maps each drizzleConfig.dialect to its getTableConfig import:

switch (drizzleConfig.dialect) {
  case 'postgresql': {
    const { getTableConfig } = await import('drizzle-orm/pg-core')
    config = getTableConfig(schemaItem)
    break
  }
  case 'mysql': {
    const { getTableConfig: getMySqlTableConfig } = await import('drizzle-orm/mysql-core')
    config = getMySqlTableConfig(schemaItem)
    break
  }
  case 'sqlite': {
    const { getTableConfig: getSqliteTableConfig } = await import('drizzle-orm/sqlite-core')
    config = getSqliteTableConfig(schemaItem)
    break
  }
  case 'singlestore': {
    const { getTableConfig: getSingleStoreTableConfig } = await import('drizzle-orm/singlestore-core')
    config = getSingleStoreTableConfig(schemaItem)
    break
  }
  // add:
  case 'mssql': {
    const { getTableConfig: getMsSqlTableConfig } = await import('drizzle-orm/mssql-core')
    config = getMsSqlTableConfig(schemaItem)
    break
  }
}

drizzle-orm/mssql-core already exports getTableConfig with the same { columns, primaryKeys, ... } shape the rest of the module consumes — verified against drizzle-orm@1.0.0-beta.22. The existing primary-key resolution logic (config.primaryKeys?.[0]?.columns with a config.columns.filter(c => c.primary) fallback) should work without modification for mssqlTable.

2. Recognize MSSQL tables in isTable(...)

isTable from drizzle-orm already returns true for mssqlTable-produced instances, so no change needed there — just flagging so reviewers can confirm.

3. Default driver path

The drizzleImport default (~~/server/utils/drizzle) is dialect-agnostic; users plug in their own instance (drizzle({ connection, schema }) from drizzle-orm/node-mssql). No change needed.

4. Tests / fixtures

Add an MSSQL fixture parallel to the existing Postgres/MySQL/SQLite ones — a minimal mssqlTable schema and a test asserting that collections are generated for it and a basic findMany round-trips through the generated REST endpoint.

Alternative

Additional context

While diagnosing the MSSQL blocker, I hit a second crash that's independent of dialect:

TypeError: Right-hand side of 'instanceof' is not an object
    at is (drizzle-orm/entity.js:6:12)
    at nuxt-drizzle/dist/module.mjs:128:39  // `is(schemaItem, Relations)`

module.mjs imports Relations from the drizzle-orm root, but in drizzle-orm@1.0.0-beta.22 that named export no longer exists — the API moved to Relation (singular), defineRelations, and createRelationsHelper (verified in drizzle-orm/index.d.ts).

This means @rstore/nuxt-drizzle@0.8.4 is additionally incompatible with the 1.0 line of drizzle-orm, even on dialects that are in the switch. For the MSSQL support work it's worth resolving together, since most MSSQL users will be on drizzle-orm ≥ 1.0 (where MSSQL first landed).

Suggested fix: migrate the relations-detection path from the legacy Relations class to defineRelations / the new buildRelations helpers.

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.

[linear]

NEXT-2371