supabase-test 0.0.1 → 0.0.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -11,12 +11,9 @@
11
11
  <a href="https://github.com/launchql/launchql/blob/main/LICENSE">
12
12
  <img height="20" src="https://img.shields.io/badge/license-MIT-blue.svg"/>
13
13
  </a>
14
- <a href="https://www.npmjs.com/package/supabase-test">
15
- <img height="20" src="https://img.shields.io/github/package-json/v/launchql/launchql?filename=packages%2Fsupabase-test%2Fpackage.json"/>
16
- </a>
17
14
  </p>
18
15
 
19
- `supabase-test` gives you instant, isolated PostgreSQL databases for each test — with automatic transaction rollbacks, context switching, and clean seeding. Forget flaky tests and brittle environments. Write real SQL. Get real coverage. Stay fast.
16
+ `supabase-test` is a Supabase-optimized version of `pgsql-test` with Supabase defaults baked in. It provides instant, isolated PostgreSQL databases for testing with automatic transaction rollbacks, context switching, and clean seeding configured for Supabase's local development environment.
20
17
 
21
18
  ## Install
22
19
 
@@ -32,37 +29,19 @@ npm install supabase-test
32
29
  * 🌱 **Flexible seeding** — run `.sql` files, programmatic seeds, or even load fixtures
33
30
  * 🧪 **Compatible with any async runner** — works with `Jest`, `Mocha`, etc.
34
31
  * 🧹 **Auto teardown** — no residue, no reboots, just clean exits
32
+ * 🎯 **Supabase defaults** — pre-configured for Supabase local development (port 54322, `supabase_admin` user)
35
33
 
36
- ### LaunchQL migrations
37
-
38
- Part of the [LaunchQL](https://github.com/launchql) ecosystem, `supabase-test` is built to pair seamlessly with our TypeScript-based [Sqitch](https://sqitch.org/) engine rewrite:
39
-
40
- * 🚀 **Lightning-fast migrations** — powered by LaunchQL’s native deployer (10x faster than legacy Sqitch)
41
- * 🔧 **Composable test scaffolds** — integrate with full LaunchQL stacks or use standalone
34
+ ## Supabase Defaults
42
35
 
36
+ This package automatically uses Supabase's local development defaults:
43
37
 
44
- ## Table of Contents
38
+ * **Port:** `54322` (Supabase's default PostgreSQL port)
39
+ * **User:** `supabase_admin`
40
+ * **Password:** `postgres`
45
41
 
46
- 1. [Install](#install)
47
- 2. [Features](#features)
48
- 3. [Quick Start](#-quick-start)
49
- 4. [`getConnections()` Overview](#getconnections-overview)
50
- 5. [PgTestClient API Overview](#pgtestclient-api-overview)
51
- 6. [Usage Examples](#usage-examples)
52
- * [Basic Setup](#-basic-setup)
53
- * [Role-Based Context](#-role-based-context)
54
- * [Seeding System](#-seeding-system)
55
- * [SQL File Seeding](#-sql-file-seeding)
56
- * [Programmatic Seeding](#-programmatic-seeding)
57
- * [CSV Seeding](#️-csv-seeding)
58
- * [JSON Seeding](#️-json-seeding)
59
- * [Sqitch Seeding](#️-sqitch-seeding)
60
- * [LaunchQL Seeding](#-launchql-seeding)
61
- 7. [`getConnections() Options` ](#getconnections-options)
62
- 8. [Disclaimer](#disclaimer)
42
+ These defaults are applied automatically, but can be overridden by passing options to `getConnections()`.
63
43
 
64
-
65
- ## ✨ Quick Start
44
+ ## Quick Start
66
45
 
67
46
  ```ts
68
47
  import { getConnections } from 'supabase-test';
@@ -75,93 +54,30 @@ beforeAll(async () => {
75
54
  });
76
55
 
77
56
  afterAll(() => teardown());
57
+ beforeEach(() => db.beforeEach());
58
+ afterEach(() => db.afterEach());
78
59
  ```
79
60
 
80
- ## `getConnections()` Overview
81
-
82
- ```ts
83
- import { getConnections } from 'supabase-test';
84
-
85
- // Complete object destructuring
86
- const { pg, db, admin, teardown, manager } = await getConnections();
87
-
88
- // Most common pattern
89
- const { db, teardown } = await getConnections();
90
- ```
91
-
92
- The `getConnections()` helper sets up a fresh PostgreSQL test database and returns a structured object with:
93
-
94
- * `pg`: a `PgTestClient` connected as the root or superuser — useful for administrative setup or introspection
95
- * `db`: a `PgTestClient` connected as the app-level user — used for running tests with RLS and granted permissions
96
- * `admin`: a `DbAdmin` utility for managing database state, extensions, roles, and templates
97
- * `teardown()`: a function that shuts down the test environment and database pool
98
- * `manager`: a shared connection pool manager (`PgTestConnector`) behind both clients
99
-
100
- Together, these allow fast, isolated, role-aware test environments with per-test rollback and full control over setup and teardown.
101
-
102
- The `PgTestClient` returned by `getConnections()` is a fully-featured wrapper around `pg.Pool`. It provides:
103
-
104
- * Automatic transaction and savepoint management for test isolation
105
- * Easy switching of role-based contexts for RLS testing
106
- * A clean, high-level API for integration testing PostgreSQL systems
107
-
108
- ## `PgTestClient` API Overview
109
-
110
- ```ts
111
- let pg: PgTestClient;
112
- let teardown: () => Promise<void>;
113
-
114
- beforeAll(async () => {
115
- ({ pg, teardown } = await getConnections());
116
- });
117
-
118
- beforeEach(() => pg.beforeEach());
119
- afterEach(() => pg.afterEach());
120
- afterAll(() => teardown());
121
- ```
122
-
123
- The `PgTestClient` returned by `getConnections()` wraps a `pg.Client` and provides convenient helpers for query execution, test isolation, and context switching.
124
-
125
- ### Common Methods
126
-
127
- * `query(sql, values?)` – Run a raw SQL query and get the `QueryResult`
128
- * `beforeEach()` – Begins a transaction and sets a savepoint (called at the start of each test)
129
- * `afterEach()` – Rolls back to the savepoint and commits the outer transaction (cleans up test state)
130
- * `setContext({ key: value })` – Sets PostgreSQL config variables (like `role`) to simulate RLS contexts
131
- * `any`, `one`, `oneOrNone`, `many`, `manyOrNone`, `none`, `result` – Typed query helpers for specific result expectations
61
+ ## Usage
132
62
 
133
- These methods make it easier to build expressive and isolated integration tests with strong typing and error handling.
134
-
135
- The `PgTestClient` returned by `getConnections()` is a fully-featured wrapper around `pg.Pool`. It provides:
136
-
137
- * Automatic transaction and savepoint management for test isolation
138
- * Easy switching of role-based contexts for RLS testing
139
- * A clean, high-level API for integration testing PostgreSQL systems
140
-
141
- ## Usage Examples
142
-
143
- ### ⚡ Basic Setup
63
+ ### Basic Setup
144
64
 
145
65
  ```ts
146
66
  import { getConnections } from 'supabase-test';
147
67
 
148
- let db; // A fully wrapped PgTestClient using pg.Pool with savepoint-based rollback per test
149
- let teardown;
68
+ let db, teardown;
150
69
 
151
70
  beforeAll(async () => {
152
71
  ({ db, teardown } = await getConnections());
153
-
72
+
73
+ // Setup schema
154
74
  await db.query(`
155
75
  CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT);
156
- CREATE TABLE posts (id SERIAL PRIMARY KEY, user_id INT REFERENCES users(id), content TEXT);
157
-
158
76
  INSERT INTO users (name) VALUES ('Alice'), ('Bob');
159
- INSERT INTO posts (user_id, content) VALUES (1, 'Hello world!'), (2, 'Graphile is cool!');
160
77
  `);
161
78
  });
162
79
 
163
80
  afterAll(() => teardown());
164
-
165
81
  beforeEach(() => db.beforeEach());
166
82
  afterEach(() => db.afterEach());
167
83
 
@@ -171,344 +87,77 @@ test('user count starts at 2', async () => {
171
87
  });
172
88
  ```
173
89
 
174
- ### 🔐 Role-Based Context
175
-
176
-
177
- The `supabase-test` framework provides powerful tools to simulate authentication contexts during tests, which is particularly useful when testing Row-Level Security (RLS) policies.
178
-
179
- #### Setting Test Context
180
-
181
- Use `setContext()` to simulate different user roles and JWT claims:
182
-
183
- ```ts
184
- db.setContext({
185
- role: 'authenticated',
186
- 'jwt.claims.user_id': '123',
187
- 'jwt.claims.org_id': 'acme'
188
- });
189
- ```
190
-
191
- This applies the settings using `SET LOCAL` statements, ensuring they persist only for the current transaction and maintain proper isolation between tests.
192
-
193
- #### Testing Role-Based Access
194
-
195
- ```ts
196
- describe('authenticated role', () => {
197
- beforeEach(async () => {
198
- db.setContext({ role: 'authenticated' });
199
- await db.beforeEach();
200
- });
201
-
202
- afterEach(() => db.afterEach());
203
-
204
- it('runs as authenticated', async () => {
205
- const res = await db.query(`SELECT current_setting('role', true) AS role`);
206
- expect(res.rows[0].role).toBe('authenticated');
207
- });
208
- });
209
- ```
210
-
211
- #### Database Connection Options
212
-
213
- For non-superuser testing, use the connection options described in the [options](#getconnections-options) section. The `db.connection` property allows you to customize the non-privileged user account for your tests.
214
-
215
- Use `setContext()` to simulate Role-Based Access Control (RBAC) during tests. This is useful when testing Row-Level Security (RLS) policies. Your actual server should manage role/user claims via secure tokens (e.g., setting `current_setting('jwt.claims.user_id')`), but this interface helps emulate those behaviors in test environments.
216
-
217
- #### Common Testing Scenarios
218
-
219
- This approach enables testing various access patterns:
220
- - Authenticated vs. anonymous user access
221
- - Per-user data filtering
222
- - Admin privilege bypass behavior
223
- - Custom claim-based restrictions (organization membership, admin status)
224
-
225
- > **Note:** While this interface helps simulate RBAC for testing, your production server should manage user/role claims via secure authentication tokens, typically by setting values like `current_setting('jwt.claims.user_id')` through proper authentication middleware.
226
-
227
- ### 🌱 Seeding System
90
+ ### Overriding Supabase Defaults
228
91
 
229
- The second argument to `getConnections()` is an optional array of `SeedAdapter` objects:
92
+ You can override the Supabase defaults by passing options:
230
93
 
231
94
  ```ts
232
- const { db, teardown } = await getConnections(getConnectionOptions, seedAdapters);
233
- ```
234
-
235
- This array lets you fully customize how your test database is seeded. You can compose multiple strategies:
236
-
237
- * [`seed.sqlfile()`](#-sql-file-seeding) – Execute raw `.sql` files from disk
238
- * [`seed.fn()`](#-programmatic-seeding) – Run JavaScript/TypeScript logic to programmatically insert data
239
- * [`seed.csv()`](#️-csv-seeding) – Load tabular data from CSV files
240
- * [`seed.json()`](#️-json-seeding) – Use in-memory objects as seed data
241
- * [`seed.sqitch()`](#️-sqitch-seeding) – Deploy a Sqitch-compatible migration project
242
- * [`seed.launchql()`](#-launchql-seeding) – Apply a LaunchQL module using `deployFast()` (compatible with sqitch)
243
-
244
- > ✨ **Default Behavior:** If no `SeedAdapter[]` is passed, LaunchQL seeding is assumed. This makes `supabase-test` zero-config for LaunchQL-based projects.
245
-
246
- This composable system allows you to mix-and-match data setup strategies for flexible, realistic, and fast database tests.
247
-
248
- ### 🔌 SQL File Seeding
249
-
250
- Use `.sql` files to set up your database state before tests:
251
-
252
- ```ts
253
- import path from 'path';
254
- import { getConnections, seed } from 'supabase-test';
255
-
256
- const sql = (f: string) => path.join(__dirname, 'sql', f);
257
-
258
- let db;
259
- let teardown;
260
-
261
- beforeAll(async () => {
262
- ({ db, teardown } = await getConnections({}, [
263
- seed.sqlfile([
264
- sql('schema.sql'),
265
- sql('fixtures.sql')
266
- ])
267
- ]));
268
- });
269
-
270
- afterAll(async () => {
271
- await teardown();
272
- });
273
- ```
274
-
275
- ### 🧠 Programmatic Seeding
276
-
277
- Use JavaScript functions to insert seed data:
278
-
279
- ```ts
280
- import { getConnections, seed } from 'supabase-test';
281
-
282
- let db;
283
- let teardown;
284
-
285
- beforeAll(async () => {
286
- ({ db, teardown } = await getConnections({}, [
287
- seed.fn(async ({ pg }) => {
288
- await pg.query(`
289
- INSERT INTO users (name) VALUES ('Seeded User');
290
- `);
291
- })
292
- ]));
293
- });
294
- ```
295
-
296
- ## 🗃️ CSV Seeding
297
-
298
- You can load tables from CSV files using `seed.csv({ ... })`. CSV headers must match the table column names exactly. This is useful for loading stable fixture data for integration tests or CI environments.
299
-
300
- ```ts
301
- import path from 'path';
302
- import { getConnections, seed } from 'supabase-test';
303
-
304
- const csv = (file: string) => path.resolve(__dirname, '../csv', file);
305
-
306
- let db;
307
- let teardown;
308
-
309
- beforeAll(async () => {
310
- ({ db, teardown } = await getConnections({}, [
311
- // Create schema
312
- seed.fn(async ({ pg }) => {
313
- await pg.query(`
314
- CREATE TABLE users (
315
- id SERIAL PRIMARY KEY,
316
- name TEXT NOT NULL
317
- );
318
-
319
- CREATE TABLE posts (
320
- id SERIAL PRIMARY KEY,
321
- user_id INT REFERENCES users(id),
322
- content TEXT NOT NULL
323
- );
324
- `);
325
- }),
326
- // Load from CSV
327
- seed.csv({
328
- users: csv('users.csv'),
329
- posts: csv('posts.csv')
330
- }),
331
- // Adjust SERIAL sequences to avoid conflicts
332
- seed.fn(async ({ pg }) => {
333
- await pg.query(`SELECT setval(pg_get_serial_sequence('users', 'id'), (SELECT MAX(id) FROM users));`);
334
- await pg.query(`SELECT setval(pg_get_serial_sequence('posts', 'id'), (SELECT MAX(id) FROM posts));`);
335
- })
336
- ]));
337
- });
338
-
339
- afterAll(() => teardown());
340
-
341
- it('has loaded rows', async () => {
342
- const res = await db.query('SELECT COUNT(*) FROM users');
343
- expect(+res.rows[0].count).toBeGreaterThan(0);
344
- });
345
- ```
346
-
347
- ## 🗃️ JSON Seeding
348
-
349
- You can seed tables using in-memory JSON objects. This is useful when you want fast, inline fixtures without managing external files.
350
-
351
- ```ts
352
- import { getConnections, seed } from 'supabase-test';
353
-
354
- let db;
355
- let teardown;
356
-
357
- beforeAll(async () => {
358
- ({ db, teardown } = await getConnections({}, [
359
- // Create schema
360
- seed.fn(async ({ pg }) => {
361
- await pg.query(`
362
- CREATE SCHEMA custom;
363
- CREATE TABLE custom.users (
364
- id SERIAL PRIMARY KEY,
365
- name TEXT NOT NULL
366
- );
367
-
368
- CREATE TABLE custom.posts (
369
- id SERIAL PRIMARY KEY,
370
- user_id INT REFERENCES custom.users(id),
371
- content TEXT NOT NULL
372
- );
373
- `);
374
- }),
375
- // Seed with in-memory JSON
376
- seed.json({
377
- 'custom.users': [
378
- { id: 1, name: 'Alice' },
379
- { id: 2, name: 'Bob' }
380
- ],
381
- 'custom.posts': [
382
- { id: 1, user_id: 1, content: 'Hello world!' },
383
- { id: 2, user_id: 2, content: 'Graphile is cool!' }
384
- ]
385
- }),
386
- // Fix SERIAL sequences
387
- seed.fn(async ({ pg }) => {
388
- await pg.query(`SELECT setval(pg_get_serial_sequence('custom.users', 'id'), (SELECT MAX(id) FROM custom.users));`);
389
- await pg.query(`SELECT setval(pg_get_serial_sequence('custom.posts', 'id'), (SELECT MAX(id) FROM custom.posts));`);
390
- })
391
- ]));
392
- });
393
-
394
- afterAll(() => teardown());
395
-
396
- it('has loaded rows', async () => {
397
- const res = await db.query('SELECT COUNT(*) FROM custom.users');
398
- expect(+res.rows[0].count).toBeGreaterThan(0);
399
- });
400
- ```
401
-
402
- ## 🏗️ Sqitch Seeding
403
-
404
- *Note: While compatible with Sqitch syntax, LaunchQL uses its own high-performance [TypeScript-based deploy engine.](#-launchql-seeding) that we encourage using for sqitch projects*
405
-
406
- You can seed your test database using a Sqitch project but with significantly improved performance by leveraging LaunchQL's TypeScript deployment engine:
407
-
408
- ```ts
409
- import path from 'path';
410
- import { getConnections, seed } from 'supabase-test';
411
-
412
- const cwd = path.resolve(__dirname, '../path/to/sqitch');
95
+ import { getConnections } from 'supabase-test';
413
96
 
414
- beforeAll(async () => {
415
- ({ db, teardown } = await getConnections({}, [
416
- seed.sqitch(cwd)
417
- ]));
97
+ const { db, teardown } = await getConnections({
98
+ pg: {
99
+ port: 5432, // Override port
100
+ host: 'custom-host'
101
+ },
102
+ db: {
103
+ connection: {
104
+ user: 'custom_user',
105
+ password: 'custom_password'
106
+ }
107
+ }
418
108
  });
419
109
  ```
420
110
 
421
- This works for any Sqitch-compatible module, now accelerated by LaunchQL's deployment tooling.
111
+ ### LaunchQL Seeding
422
112
 
423
- ## 🚀 LaunchQL Seeding
424
-
425
- If your project uses LaunchQL modules with a precompiled `launchql.plan`, you can use `supabase-test` with **zero configuration**. Just call `getConnections()` — and it *just works*:
113
+ By default, `getConnections()` uses LaunchQL seeding from the current directory:
426
114
 
427
115
  ```ts
428
116
  import { getConnections } from 'supabase-test';
429
117
 
430
- let db, teardown;
431
-
432
- beforeAll(async () => {
433
- ({ db, teardown } = await getConnections()); // 🚀 LaunchQL deployFast() is used automatically - up to 10x faster than traditional Sqitch!
434
- });
118
+ const { db, teardown } = await getConnections();
119
+ // Automatically deploys LaunchQL module from current directory
435
120
  ```
436
121
 
437
- This works out of the box because `supabase-test` uses the high-speed `deployFast()` function by default, applying any compiled LaunchQL schema located in the current working directory (`process.cwd()`).
438
-
439
- If you want to specify a custom path to your LaunchQL module, use `seed.launchql()` explicitly:
122
+ ### Custom Seeding
440
123
 
124
+ You can use any of the seeding strategies from `pgsql-test`:
441
125
 
442
126
  ```ts
443
- import path from 'path';
444
127
  import { getConnections, seed } from 'supabase-test';
128
+ import path from 'path';
445
129
 
446
- const cwd = path.resolve(__dirname, '../path/to/launchql');
130
+ const sql = (f: string) => path.join(__dirname, 'sql', f);
447
131
 
448
- beforeAll(async () => {
449
- ({ db, teardown } = await getConnections({}, [
450
- seed.launchql(cwd) // uses deployFast() - up to 10x faster than traditional Sqitch!
451
- ]));
452
- });
132
+ const { db, teardown } = await getConnections({}, [
133
+ seed.sqlfile([
134
+ sql('schema.sql'),
135
+ sql('fixtures.sql')
136
+ ])
137
+ ]);
453
138
  ```
454
139
 
455
- ## Why LaunchQL's Approach?
456
-
457
- LaunchQL provides the best of both worlds:
458
-
459
- 1. **Sqitch Compatibility**: Keep your familiar Sqitch syntax and migration approach
460
- 2. **TypeScript Performance**: Our TS-rewritten deployment engine delivers up to 10x faster schema deployments
461
- 3. **Developer Experience**: Tight feedback loops with near-instant schema setup for tests
462
- 4. **CI Optimization**: Dramatically reduced test suite run times with optimized deployment
140
+ ## API
463
141
 
464
- By maintaining Sqitch compatibility while supercharging performance, LaunchQL enables you to keep your existing migration patterns while enjoying the speed benefits of our TypeScript engine.
142
+ This package re-exports everything from `pgsql-test`, so all the same APIs are available:
465
143
 
466
- ## `getConnections` Options
144
+ * `getConnections()` - Main entry point (with Supabase defaults)
145
+ * `PgTestClient` - Database client with test utilities
146
+ * `seed` - Seeding adapters (sqlfile, csv, json, launchql, sqitch, etc.)
147
+ * `DbAdmin` - Database administration utilities
467
148
 
468
- This table documents the available options for the `getConnections` function. The options are passed as a combination of `pg` and `db` configuration objects.
149
+ See the [pgsql-test documentation](https://github.com/launchql/launchql/tree/main/packages/pgsql-test) for complete API details.
469
150
 
470
- ### `db` Options (PgTestConnectionOptions)
151
+ ## Differences from pgsql-test
471
152
 
472
- | Option | Type | Default | Description |
473
- | ------------------------ | ---------- | ---------------- | --------------------------------------------------------------------------- |
474
- | `db.extensions` | `string[]` | `[]` | Array of PostgreSQL extensions to include in the test database |
475
- | `db.cwd` | `string` | `process.cwd()` | Working directory used for LaunchQL/Sqitch projects |
476
- | `db.connection.user` | `string` | `'app_user'` | User for simulating RLS via `setContext()` |
477
- | `db.connection.password` | `string` | `'app_password'` | Password for RLS test user |
478
- | `db.connection.role` | `string` | `'anonymous'` | Default role used during `setContext()` |
479
- | `db.template` | `string` | `undefined` | Template database used for faster test DB creation |
480
- | `db.rootDb` | `string` | `'postgres'` | Root database used for administrative operations (e.g., creating databases) |
481
- | `db.prefix` | `string` | `'db-'` | Prefix used when generating test database names |
153
+ The only difference is that `getConnections()` has Supabase defaults pre-configured:
482
154
 
483
- ### `pg` Options (PgConfig)
155
+ * Port defaults to `54322` instead of `5432`
156
+ * User defaults to `supabase_admin` instead of `postgres`
157
+ * Password defaults to `postgres` instead of `password`
484
158
 
485
- Environment variables will override these options when available:
159
+ All other functionality is identical to `pgsql-test`.
486
160
 
487
- * `PGHOST`, `PGPORT`, `PGUSER`, `PGPASSWORD`, `PGDATABASE`
488
-
489
- | Option | Type | Default | Description |
490
- | ------------- | -------- | ------------- | ----------------------------------------------- |
491
- | `pg.user` | `string` | `'postgres'` | Superuser for PostgreSQL |
492
- | `pg.password` | `string` | `'password'` | Password for the PostgreSQL superuser |
493
- | `pg.host` | `string` | `'localhost'` | Hostname for PostgreSQL |
494
- | `pg.port` | `number` | `5423` | Port for PostgreSQL |
495
- | `pg.database` | `string` | `'postgres'` | Default database used when connecting initially |
496
-
497
- ### Usage
498
-
499
- ```ts
500
- const { conn, db, teardown } = await getConnections({
501
- pg: { user: 'postgres', password: 'secret' },
502
- db: {
503
- extensions: ['uuid-ossp'],
504
- cwd: '/path/to/project',
505
- connection: { user: 'test_user', password: 'secret', role: 'authenticated' },
506
- template: 'test_template',
507
- prefix: 'test_',
508
- rootDb: 'postgres'
509
- }
510
- });
511
- ```
512
161
 
513
162
  ## Related LaunchQL Tooling
514
163
 
@@ -553,5 +202,4 @@ const { conn, db, teardown } = await getConnections({
553
202
 
554
203
  AS DESCRIBED IN THE LICENSES, THE SOFTWARE IS PROVIDED "AS IS", AT YOUR OWN RISK, AND WITHOUT WARRANTIES OF ANY KIND.
555
204
 
556
- No developer or entity involved in creating this software will be liable for any claims or damages whatsoever associated with your use, inability to use, or your interaction with other users of the code, including any direct, indirect, incidental, special, exemplary, punitive or consequential damages, or loss of profits, cryptocurrencies, tokens, or anything else of value.
557
-
205
+ No developer or entity involved in creating this software will be liable for any claims or damages whatsoever associated with your use, inability to use, or your interaction with other users of the code, including any direct, indirect, incidental, special, exemplary, punitive or consequential damages, or loss of profits, cryptocurrencies, tokens, or anything else of value.
package/connect.d.ts CHANGED
@@ -1,19 +1,11 @@
1
- import { PgTestConnectionOptions } from '@launchql/types';
2
- import { PgConfig } from 'pg-env';
3
- import { DbAdmin } from './admin';
4
- import { PgTestConnector } from './manager';
5
- import { SeedAdapter } from './seed/types';
6
- import { PgTestClient } from './test-client';
7
- export declare const getPgRootAdmin: (connOpts?: PgTestConnectionOptions) => DbAdmin;
8
- export interface GetConnectionOpts {
9
- pg?: Partial<PgConfig>;
10
- db?: Partial<PgTestConnectionOptions>;
11
- }
12
- export interface GetConnectionResult {
13
- pg: PgTestClient;
14
- db: PgTestClient;
15
- admin: DbAdmin;
16
- teardown: () => Promise<void>;
17
- manager: PgTestConnector;
18
- }
19
- export declare const getConnections: (cn?: GetConnectionOpts, seedAdapters?: SeedAdapter[]) => Promise<GetConnectionResult>;
1
+ import { getConnections as getPgConnections, type GetConnectionOpts, type GetConnectionResult } from 'pgsql-test';
2
+ /**
3
+ * Get connections with Supabase defaults applied.
4
+ * Environment variables take precedence over Supabase defaults.
5
+ * User-provided options take precedence over both.
6
+ *
7
+ * Note: Uses PGUSER/PGPASSWORD for both pg config and db.connection
8
+ * (DB_CONNECTION_ROLE can still be used to override the default role)
9
+ */
10
+ export declare const getConnections: (cn?: GetConnectionOpts, seedAdapters?: Parameters<typeof getPgConnections>[1]) => Promise<GetConnectionResult>;
11
+ export type { GetConnectionOpts, GetConnectionResult };