postgres-schema-migrations 6.0.0

package/.editorconfig

@@ -0,0 +1,9 @@
+root = true
+
+[*]
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+indent_style = space
+indent_size = 2

package/.fitcommitjsrc.yml

@@ -0,0 +1,22 @@
+---
+validators:
+  lineLength:
+    enabled: true
+    maxLineLength: 72
+    subjectMaxLength: 50
+  ticketCode:
+    enabled: false
+  emptyLines:
+    enabled: true
+    emptyLines: 1
+  tags:
+    enabled: false
+  subjectTense:
+    enabled: true
+  subjectPeriod:
+    enabled: false
+  capitalizedSubject:
+    # to allow npm version commits e.g. 1.0.0
+    enabled: false
+  wip:
+    enabled: true

package/.gitattributes

@@ -0,0 +1 @@
+package-lock.json -diff

package/.github/workflows/node.js.yml

@@ -0,0 +1,31 @@
+# This workflow will do a clean install of node dependencies, build the source code and run tests across different versions of node
+# For more information see: https://help.github.com/actions/language-and-framework-guides/using-nodejs-with-github-actions
+
+name: Node.js CI
+
+on:
+  push:
+    branches: [ master ]
+  pull_request:
+    branches: [ master ]
+
+jobs:
+  build:
+
+    runs-on: ubuntu-latest
+
+    strategy:
+      matrix:
+        node-version: [12.x, 14.x, 16.x]
+        # See supported Node.js release schedule at https://nodejs.org/en/about/releases/
+
+    steps:
+    - uses: actions/checkout@v2
+    - name: Use Node.js ${{ matrix.node-version }}
+      uses: actions/setup-node@v2
+      with:
+        node-version: ${{ matrix.node-version }}
+    - run: npm ci
+    - run: npm run
+    - run: docker pull postgres:9.4
+    - run: npm test

package/.prettierignore

@@ -0,0 +1 @@
+dist

package/.prettierrc

@@ -0,0 +1,5 @@
+{
+  "semi": false,
+  "trailingComma": "all",
+  "bracketSpacing": false
+}

package/CHANGELOG.md

@@ -0,0 +1,30 @@
+# Changelog
+
+## 5.3.0
+
+- [DEPRECATION] Deprecate `createDb`
+- Add `ensureDatabaseExists` to check/create database in `migrate`
+
+## 5.1.0
+
+- Validate migration ordering when loading files (instead of when applying migrations)
+- Expose `loadMigrationFiles` publicly, which can be used to validate files in e.g. a pre-push hook
+- Add `pg-validate-migrations` bin script
+
+## 5.0.0
+
+- [BREAKING] Update `pg` to version 8. See the [pg changelog](https://github.com/brianc/node-postgres/blob/master/CHANGELOG.md#pg800) for details.
+
+## 4.0.0
+
+- [BREAKING] Updated whole project to TypeScript
+  - some types might differ, no functional change
+  - 21a7ee6
+- [BREAKING] Increase required Node.js version to v10
+  - 24bf9b7
+- [BREAKING] Ensure file extension includes `.`
+  - b8ed85a
+- [BREAKING] Implement advisory locks to manage concurrency
+  - 73b5ade
+- Optionally accept a `pg` client for database connections
+  - ad81ed9 c246ad3

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2016 Momentum Financial Technology
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,336 @@
+# Postgres schema migrations
+
+![GitHub Actions](https://github.com/ThomWright/postgres-migrations/actions/workflows/node.js.yml/badge.svg)
+[![npm](https://img.shields.io/npm/v/postgres-migrations.svg)](https://www.npmjs.com/package/postgres-migrations)
+[![David](https://img.shields.io/david/ThomWright/postgres-migrations.svg)](https://david-dm.org/ThomWright/postgres-migrations)
+[![David](https://img.shields.io/david/dev/ThomWright/postgres-migrations.svg)](https://david-dm.org/ThomWright/postgres-migrations)
+
+This is a fork of Thom Wright's [PostgreSQL migration library](https://github.com/ThomWright/postgres-migrations) which allows for a schema to be specified and for separate migrations to be tracked based on schema. Using Postgres schema namespaces make it easy to reuse database code across projects, so it can be helpful to track migrations for different namespaces.
+
+A PostgreSQL migration library inspired by the Stack Overflow system described in [Nick Craver's blog](http://nickcraver.com/blog/2016/05/03/stack-overflow-how-we-do-deployment-2016-edition/#database-migrations).
+
+Migrations are defined in sequential SQL files, for example:
+
+```text
+migrations
+├ 1_create-table.sql
+├ 2_alter-table.sql
+└ 3_add-index.sql
+```
+
+Requires Node 10.17.0+
+
+Supports PostgreSQL 9.4+
+
+## API
+
+There are two ways to use the API.
+
+Either, pass a database connection config object:
+
+```typescript
+import {migrate} from "postgres-migrations"
+
+async function() {
+  const dbConfig = {
+    database: "database-name",
+    user: "postgres",
+    password: "password",
+    host: "localhost",
+    port: 5432,
+
+    // Default: false for backwards-compatibility
+    // This might change!
+    ensureDatabaseExists: true,
+
+    // Default: "postgres"
+    // Used when checking/creating "database-name"
+    defaultDatabase: "postgres"
+  }
+
+  await migrate(dbConfig, "path/to/migration/files")
+}
+```
+
+Or, pass a `pg` client:
+
+```typescript
+import {migrate} from "postgres-migrations"
+
+async function() {
+  const dbConfig = {
+    database: "database-name",
+    user: "postgres",
+    password: "password",
+    host: "localhost",
+    port: 5432,
+  }
+
+  // Note: when passing a client, it is assumed that the database already exists
+  const client = new pg.Client(dbConfig) // or a Pool, or a PoolClient
+  await client.connect()
+  try {
+    await migrate({client}, "path/to/migration/files")
+  } finally {
+    await client.end()
+  }
+}
+```
+
+### Namespaced migrations 
+
+To track migrations within a given schema, just pass an additional `{schema: "your_schema_name"}` parameter to `migrate`, as in:
+
+```
+  try {
+    await migrate({client}, "path/to/schema/migration/files", {schema: "schema_name"})
+  } finally {
+    await client.end()
+  }
+```
+
+Without specifying this parameter, this library will default to the `public` schema.
+
+### Validating migration files
+
+Occasionally, if two people are working on the same codebase independently, they might both create a migration at the same time. For example, `5_add-table.sql` and `5_add-column.sql`. If these both get pushed, there will be a conflict.
+
+While the migration system will notice this and refuse to apply the migrations, it can be useful to catch this as early as possible.
+
+The `loadMigrationFiles` function can be used to check if the migration files satisfy the rules.
+
+Alternatively, use the `pg-validate-migrations` bin script: `pg-validate-migrations "path/to/migration/files"`.
+
+## Design decisions
+
+### No down migrations
+
+There is deliberately no concept of a 'down' migration. In the words of Nick Craver:
+
+> If we needed to reverse something, we could just push another migration negating whatever we did that went boom ... Why roll back when you can roll forward?
+
+### Simple ordering
+
+Migrations are guaranteed to run in the same order every time, on every system.
+
+Some migration systems use timestamps for ordering migrations, where the timestamp represents when the migration file was created. This doesn't guarantee that the migrations will be run in the same order on every system.
+
+For example, imagine Developer A creates a migration file in a branch. The next day, Developer B creates a migration in master, and deploys it to production. On day three Developer A merges in their branch and deploys to production.
+
+The production database sees the migrations applied out of order with respect to their creation time. Any new development database will run the migrations in the timestamp order.
+
+### The `migrations` table
+
+A `migrations` table is created as the first migration, before any user-supplied migrations. This keeps track of all the migrations which have already been run.
+
+### Hash checks for previous migrations
+
+Previously run migration scripts shouldn't be modified, since we want the process to be repeated in the same way for every new environment.
+
+This is enforced by hashing the file contents of a migration script and storing this in `migrations` table. Before running a migration, the previously run scripts are hashed and checked against the database to ensure they haven't changed.
+
+### Each migration runs in a transaction
+
+Running in a transaction ensures each migration is atomic. Either it completes successfully, or it is rolled back and the process is aborted.
+
+An exception is made when `-- postgres-migrations disable-transaction` is included at the top of the migration file. This allows migrations such as `CREATE INDEX CONCURRENTLY` which cannot be run inside a transaction.
+
+### Abort on errors
+
+If anything fails, the migration in progress is rolled back and an exception is thrown.
+
+## Concurrency
+
+As of v4, [advisory locks](https://www.postgresql.org/docs/9.4/explicit-locking.html#ADVISORY-LOCKS) are used to control concurrency. If two migration runs are kicked off concurrently, one will wait for the other to finish before starting. Once a process has acquired a lock, it will run each of the pending migrations before releasing the lock again.
+
+Logs from two processes `A` and `B` running concurrently should look something like the following.
+
+```text
+B Connected to database
+B Acquiring advisory lock...
+A Connected to database
+A Acquiring advisory lock...
+B ... acquired advisory lock
+B Starting migrations
+B Starting migration: 2 migration-name
+B Finished migration: 2 migration-name
+B Starting migration: 3 another-migration-name
+B Finished migration: 3 another-migration-name
+B Successfully applied migrations: migration-name, another-migration-name
+B Finished migrations
+B Releasing advisory lock...
+B ... released advisory lock
+A ... acquired advisory lock
+A Starting migrations
+A No migrations applied
+A Finished migrations
+A Releasing advisory lock...
+A ... released advisory lock
+```
+
+Warning: the use of advisory locks will cause problems when using [transaction pooling or statement pooling in PgBouncer](http://www.pgbouncer.org/features.html). A similar system is used in Rails, [see this for an explanation of the problem](https://blog.saeloun.com/2019/09/09/rails-6-disable-advisory-locks.html).
+
+## Migration rules
+
+### Make migrations idempotent
+
+Migrations should only be run once, but this is a good principle to follow regardless.
+
+### Migrations are immutable
+
+Once applied (to production), a migration cannot be changed.
+
+This is enforced by storing a hash of the file contents for each migration in the migrations table.
+
+These hashes are checked when running migrations.
+
+### Migrations should be backwards compatible
+
+Backwards incompatible changes can usually be made in a few stages.
+
+For an example, see [this blog post](http://www.brunton-spall.co.uk/post/2014/05/06/database-migrations-done-right/).
+
+### File name
+
+A migration file must match the following pattern:
+
+`[id][separator][name][extension]`
+
+| Section   | Accepted Values                   | Description                                                                                                                      |
+| --------- | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| id        | Any integer or left zero integers | Consecutive integer ID. <br />**Must start from 1 and be consecutive, e.g. if you have migrations 1-4, the next one must be 5.** |
+| separator | `_` or `-` or nothing             |                                                                                                                                  |
+| name      | Any length text                   |                                                                                                                                  |
+| extension | `.sql` or `.js`                   | File extensions supported. **Case insensitive.**                                                                                 |
+
+Example:
+
+```text
+migrations
+├ 1_create-initial-tables.sql
+├ 1_create-initial-tables.md # Docs can go here
+├ 2-alter-initial-tables.SQL
+└ 3-alter-initial-tables-again.js
+```
+
+Or, if you want better ordering in your filesystem:
+
+```text
+migrations
+├ 00001_create-initial-tables.sql
+├ 00001_create-initial-tables.md # Docs can go here
+├ 00002-alter-initial-tables.sql
+└ 00003_alter-initial-tables-again.js
+```
+
+Migrations will be performed in the order of the ids. If ids are not consecutive or if multiple migrations have the same id, the migration run will fail.
+
+Note that file names cannot be changed later.
+
+### Javascript Migrations
+
+By using `.js` extension on your migration file you gain access to all NodeJS features and only need to export a method called `generateSql` that returns a `string` literal like:
+
+```js
+// ./migrations/helpers/create-main-table.js
+module.exports = `
+CREATE TABLE main (
+    id int primary key
+);`
+
+// ./migrations/helpers/create-secondary-table.js
+module.exports = `
+CREATE TABLE secondary (
+    id int primary key
+);`
+
+// ./migrations/1-init.js
+const createMainTable = require("./create-main-table")
+const createSecondaryTable = require("./create-secondary-table")
+
+module.exports.generateSql = () => `${createMainTable}
+${createSecondaryTable}`
+```
+
+## Tips
+
+### Date handling
+
+If you want sane date handling, it is recommended you use the following code snippet to fix a `node-postgres` [bug](https://github.com/brianc/node-postgres/issues/818):
+
+```js
+const pg = require("pg")
+
+const parseDate = (val) =>
+  val === null ? null : moment(val).format("YYYY-MM-DD")
+const DATATYPE_DATE = 1082
+pg.types.setTypeParser(DATATYPE_DATE, (val) => {
+  return val === null ? null : parseDate(val)
+})
+```
+
+### Schema migrations vs data migrations
+
+General rule: only change schemas and other static data in database migrations.
+
+When writing a migration which affects data, consider whether the migration needs to be run for all possible environments or just some specific environment. Schema changes and static data need changing for all environments. Often, data changes need to only happen in dev or prod (to fix some data), and might be better of run as one-off jobs (manually or otherwise).
+
+### Making a column NOT NULL
+
+```sql
+-- No no no nononono (at least for big tables)
+ALTER TABLE my_table ALTER COLUMN currently_nullable SET NOT NULL;
+```
+
+TL;DR don't do the above without [reading this](https://medium.com/doctolib/adding-a-not-null-constraint-on-pg-faster-with-minimal-locking-38b2c00c4d1c). It can be slow for big tables, and will lock out all writes to the table until it completes.
+
+### Creating indexes
+
+When creating indexes, there are a few important considerations.
+
+Creating an index should probably look like this:
+
+```sql
+-- postgres-migrations disable-transaction
+CREATE INDEX CONCURRENTLY IF NOT EXISTS name_of_idx
+  ON table_name (column_name);
+```
+
+- `CONCURRENTLY` - without this, writes on the table will block until the index has finished being created. However, it can't be run inside a transaction.
+- `-- postgres-migrations disable-transaction` - migrations are run inside a transaction by default. This disables that.
+- `IF NOT EXISTS` - since the transaction is disabled, it's possible to end up in a partially applied state where the index exists but the migration wasn't recorded. In this case, the migration will probably get run again. This ensures that will succeed.
+
+See the [Postgres docs on creating indexes](https://www.postgresql.org/docs/9.6/sql-createindex.html).
+
+### Avoid `IF NOT EXISTS`
+
+_Most_ of the time using `IF NOT EXISTS` is not necessary (see above for an exception). In most cases, we would be better off with a failing migration script that tells us that we tried to create a table with a duplicate name.
+
+### Use separate markdown files for complex documentation
+
+A comment that is added to a migration script can never be changed once the migration script has been deployed. For complex migration scripts, consider documenting them in a separate markdown file with the same file name as the migration script. This documentation can then be updated later if a better explanation becomes apparent.
+
+Your file structure might look something like this:
+
+```text
+- migrations
+  - 0001_complex_migration.md   <--- Contains documentation that can be updated.
+  - 0001_complex_migration.sql
+  - 0002_simple_migration.sql
+Rather than this:
+- migrations
+  - 0001_complex_migration.sql   <--- Contains documentation that can never be updated.
+  - 0002_simple_migration.sql
+```
+
+## Useful resources
+
+[Stack Overflow: How We Do Deployment - 2016 Edition (Database Migrations)](http://nickcraver.com/blog/2016/05/03/stack-overflow-how-we-do-deployment-2016-edition/#database-migrations)
+
+[Database Migrations Done Right](http://www.brunton-spall.co.uk/post/2014/05/06/database-migrations-done-right/)
+
+[Database versioning best practices](http://enterprisecraftsmanship.com/2015/08/10/database-versioning-best-practices/)
+
+## Developing `postgres-migrations`
+
+The tests require Docker to be installed. It probably helps to `docker pull postgres:9.4`.

package/ava.config.cjs

@@ -0,0 +1,4 @@
+module.exports = {
+  extensions: ["ts"],
+  require: ["ts-node/register"],
+}

package/ava.config.integration.cjs

@@ -0,0 +1,6 @@
+const baseConfig = require("./ava.config.cjs")
+
+module.exports = {
+  ...baseConfig,
+  files: ["src/**/__tests__/**/*.ts", "!src/**/__tests__/**/fixtures/**/*"],
+}

package/ava.config.unit.cjs

@@ -0,0 +1,6 @@
+const baseConfig = require("./ava.config.cjs")
+
+module.exports = {
+  ...baseConfig,
+  files: ["src/**/__unit__/**/*.ts", "!src/**/__unit__/**/fixtures/**/*"],
+}

package/dist/bin/validate.d.ts

@@ -0,0 +1,2 @@
+#!/usr/bin/env node
+export {};

package/dist/bin/validate.js

@@ -0,0 +1,14 @@
+#!/usr/bin/env node
+"use strict";
+// tslint:disable no-console
+Object.defineProperty(exports, "__esModule", { value: true });
+const process_1 = require("process");
+const files_loader_1 = require("../files-loader");
+async function main(args) {
+    const directory = args[0];
+    await files_loader_1.loadMigrationFiles(directory, (x) => console.error(x));
+}
+main(process_1.argv.slice(2)).catch((e) => {
+    console.error(`ERROR: ${e.message}`);
+    process.exit(1);
+});

package/dist/create.d.ts

@@ -0,0 +1,6 @@
+import { BasicPgClient, Config, CreateDBConfig, Logger } from "./types";
+/**
+ * @deprecated Use `migrate` instead with `ensureDatabaseExists: true`.
+ */
+export declare function createDb(dbName: string, dbConfig: CreateDBConfig, config?: Config): Promise<void>;
+export declare function runCreateQuery(dbName: string, log: Logger): (client: BasicPgClient) => Promise<void>;

package/dist/create.js

@@ -0,0 +1,64 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.runCreateQuery = exports.createDb = void 0;
+const pg = require("pg");
+const with_connection_1 = require("./with-connection");
+const DUPLICATE_DATABASE = "42P04";
+/**
+ * @deprecated Use `migrate` instead with `ensureDatabaseExists: true`.
+ */
+async function createDb(dbName, dbConfig, config = {}) {
+    if (typeof dbName !== "string") {
+        throw new Error("Must pass database name as a string");
+    }
+    const log = config.logger != null
+        ? config.logger
+        : () => {
+            //
+        };
+    if (dbConfig == null) {
+        throw new Error("No config object");
+    }
+    if ("client" in dbConfig) {
+        return runCreateQuery(dbName, log)(dbConfig.client);
+    }
+    if (typeof dbConfig.user !== "string" ||
+        typeof dbConfig.password !== "string" ||
+        typeof dbConfig.host !== "string" ||
+        typeof dbConfig.port !== "number") {
+        throw new Error("Database config problem");
+    }
+    const { user, password, host, port } = dbConfig;
+    const client = new pg.Client({
+        database: dbConfig.defaultDatabase != null ? dbConfig.defaultDatabase : "postgres",
+        user,
+        password,
+        host,
+        port,
+    });
+    client.on("error", (err) => {
+        log(`pg client emitted an error: ${err.message}`);
+    });
+    const runWith = with_connection_1.withConnection(log, runCreateQuery(dbName, log));
+    return runWith(client);
+}
+exports.createDb = createDb;
+function runCreateQuery(dbName, log) {
+    return async (client) => {
+        await client
+            .query(`CREATE DATABASE "${dbName.replace(/\"/g, '""')}"`)
+            .catch((e) => {
+            switch (e.code) {
+                case DUPLICATE_DATABASE: {
+                    log(`'${dbName}' database already exists`);
+                    return;
+                }
+                default: {
+                    log(e);
+                    throw new Error(`Error creating database. Caused by: '${e.name}: ${e.message}'`);
+                }
+            }
+        });
+    };
+}
+exports.runCreateQuery = runCreateQuery;

package/dist/file-name-parser.d.ts

@@ -0,0 +1,7 @@
+import { FileType } from "./types";
+export interface FileInfo {
+    id: number;
+    name: string;
+    type: FileType;
+}
+export declare const parseFileName: (fileName: string) => FileInfo;

package/dist/file-name-parser.js

@@ -0,0 +1,27 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.parseFileName = void 0;
+const parseId = (id) => {
+    const parsed = parseInt(id, 10);
+    if (isNaN(parsed)) {
+        throw new Error(`Migration file name should begin with an integer ID.'`);
+    }
+    return parsed;
+};
+const parseFileName = (fileName) => {
+    const result = /^(-?\d+)[-_]?(.*).(sql|js)$/gi.exec(fileName);
+    if (!result) {
+        throw new Error(`Invalid file name: '${fileName}'.`);
+    }
+    const [, id, name, type] = result;
+    const lowerType = type.toLowerCase();
+    if (lowerType !== "js" && lowerType !== "sql") {
+        throw new Error("Not a JS or SQL file");
+    }
+    return {
+        id: parseId(id),
+        name: name == null || name === "" ? fileName : name,
+        type: lowerType,
+    };
+};
+exports.parseFileName = parseFileName;

package/dist/files-loader.d.ts

@@ -0,0 +1,10 @@
+import { Logger, Migration } from "./types";
+/**
+ * Load the migration files and assert they are reasonably valid.
+ *
+ * 'Reasonably valid' in this case means obeying the file name and
+ * consecutive ordering rules.
+ *
+ * No assertions are made about the validity of the SQL.
+ */
+export declare const loadMigrationFiles: (directory: string, log?: Logger, schemaName?: string) => Promise<Array<Migration>>;

package/dist/files-loader.js

@@ -0,0 +1,39 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.loadMigrationFiles = void 0;
+const fs = require("fs");
+const path = require("path");
+const util_1 = require("util");
+const migration_file_1 = require("./migration-file");
+const validation_1 = require("./validation");
+const readDir = util_1.promisify(fs.readdir);
+const isValidFile = (fileName) => /\.(sql|js)$/gi.test(fileName);
+/**
+ * Load the migration files and assert they are reasonably valid.
+ *
+ * 'Reasonably valid' in this case means obeying the file name and
+ * consecutive ordering rules.
+ *
+ * No assertions are made about the validity of the SQL.
+ */
+const loadMigrationFiles = async (directory, 
+// tslint:disable-next-line no-empty
+log = () => { }, schemaName = "public") => {
+    log(`Loading migrations from: ${directory}`);
+    const fileNames = await readDir(directory);
+    log(`Found migration files: ${fileNames}`);
+    if (fileNames == null) {
+        return [];
+    }
+    const migrationFiles = [
+        path.join(__dirname, "migrations/0_create-migrations-table.sql"),
+        ...fileNames.map((fileName) => path.resolve(directory, fileName)),
+    ].filter(isValidFile);
+    const unorderedMigrations = await Promise.all(migrationFiles.map(migration_file_1.loadMigrationFile));
+    // Arrange in ID order
+    const orderedMigrations = unorderedMigrations.sort((a, b) => a.id - b.id);
+    validation_1.validateMigrationOrdering(orderedMigrations);
+    orderedMigrations[0].sql = orderedMigrations[0].sql.replace("CREATE TABLE IF NOT EXISTS migrations", `CREATE SCHEMA IF NOT EXISTS ${schemaName}; CREATE TABLE IF NOT EXISTS ${schemaName}.migrations`);
+    return orderedMigrations;
+};
+exports.loadMigrationFiles = loadMigrationFiles;

package/dist/index.d.ts

@@ -0,0 +1,4 @@
+export { createDb } from "./create";
+export { migrate } from "./migrate";
+export { loadMigrationFiles } from "./files-loader";
+export { ConnectionParams, CreateDBConfig, MigrateDBConfig, Logger, Config, MigrationError, } from "./types";