Vite plugin for importing SQL files as JS modules with sqlc-style annotations
npm install vite-plugin-postgres-importEver wanted to ditch those ORMs and finally learn SQL?
If you use PostgreSQL and Vite - this plugin is right for you!
Start importing .sql files with sqlc-style annotations right into your JavaScript code today!
module.sql:
``sql
-- name: Query :one
select id
from t
where id = :id;
-- name: UpdateQuery :execrows
update t
set foo = :newFoo
where id = :id;
-- name: QueryMany :many
select *
from t;
-- name: MultiStatement :many
select *
from t;
-- :one
select something
from t
limit 1;
-- :execrows
delete from t
where foo = :foo;
`
usage.js:
`js
import { Pool } from "pg";
import { Query, UpdateQuery, QueryMany, MultiStatement } from "./module.sql";
const pool = new Pool("...");
const { id } = await Query(pool, { id: 1 });
const rowsUpdated = await UpdateQuery(pool, { id: 1, newFoo: "bar" });
const array = await QueryMany(pool);
// array, object, number respectively
const [all, something, deleted] = await MultiStatement(pool, { foo: "bar" });
`
> [!Warning]
>
> Postgres does _NOT_ allow using parameters in multi-statement queries.
>
> The current implementation for them is a hackaround that involes injecting escaped values into the SQL string.
The only 4 sqlc annotations that are available are the following:
- :execresult - default if neither of the 3 below are provided, returns QueryResult.
ex.: Query
- :one - returns template argument, or the default-parsed ones from the select/returning clause.
ex.: Query
- :many - returns template argument as an array, or the default-parsed ones from the select/returning clause.
ex.: Query
- :execrows - returns number of affected rows.
ex.: Query(c): Promise
4 additional annotations not found in sqlc are available:
- :prepare - prepares the statement by passing query's name to query config.
> [!Warning]
>
> Similarly to parameters, Postgres does _NOT_ allow preparing multi-statement queries. Using :prepare on a multi-statement query will result in an error. I warned you!
> [!Warning]
>
> Don't use identical names for prepared queries, regardless whether they're in different .sql modules or not:one.sql
>
> :`
>
> sql`
> -- name: One :one :prepare
> select *
> from t
>
>
> :`
>
> sql`
> -- name: One :one :prepare
> select id
> from t
> where id = :id;
>
>
> :`
>
> js`
> import { One } from "./one.sql";
> import { One as AnotherOne } from "./another-one.sql";
>
> // definitely don't do this
> await One(c);
> await AnotherOne(c, { id: ... });
>
>
> At best, you'd get an error in the provided example, due to mismatch in provided values, and at worst, assuming different examples, you'd be getting obscure bugs related to incorrect data.
- :array - sets rowMode to 'array'. Modifies to type declarations accordingly:
ex. :execresult: Query
ex. :one: Query
ex. :many: Query
- :iterable - returns an AsyncGenerator. Once Async Iterator Helpers
are in the standard, you can use crazy piping as following:
`js`
const result = await IterableQuery<{ ... }>(c, { foo: 'bar' })
.flatMap(superComplicatedCodeThatIsMoreUsefulToRunFromJS)
.filter(Boolean)
.toArray();
Well maybe that didn't look too crazy, but if some filtering forces your squeel to become convoluted, and you're fine with moving
some of that computation to JS, you can finally do that! Or at least when that proposal is in the language, that is.
- :cursor - returns an Cursor
ex.: Query
ex. :array: Query
Path to a folder where all declaration are kept relative to rootFolder, i.e.src/sql/module.sql
a file at path will have its .d.ts file generated into ${typesFolder}/src/sql/module.sql.d.ts.tsconfig.json
Make sure you include this one in your as "${typesFolder}/*/.sql.d.ts".
_default:_ 'node_modules/@types/vite-plugin-postgres-import/'
Root folder relative to which path calculation will be happening. May be useful for some I guess.
_default:_ process.cwd()
This plugin does not connect to the database or scan a schema folder, instead naively
parsing select or returning clauses to figure out potential response types.
In a real TypeScript project you should probably still roll your own types?
And JavaScript projects still get the benefits of completions.
I primarily use this in a SvelteKit project. The only thing I modify is setting typesFolder to '.svelte-kit/types' directory, and adding a ".svelte-kit/types/*/.sql.d.ts" record to my include array in tsconfig.json.
Also, when using SvelteKit aliases you can absolutely shove all your sql modules in a src/sql directory with a $sql` alias and have module declarations generated for all of the files! Works automagically out of the box.
MIT.