Knex: Maneira correta de criar tabelas antes de tentar adicionar chaves estrangeiras usando a migração do knex?

Você está correto.

// migration: <timestamp>_create_things.js

module.exports.up = function(knex, Promise) {
  // Create referenced table before referencing table.
  return knex.schema
  .createTable('first', function(first) {
    first.increments('id').primary();
  })
  .createTable('second', function(second) {
    second.increments('id').primary();
    second.integer('first_id').references('id').inTable('first').notNull().onDelete('cascade');
  });
};

module.exports.down = function(knex, Promise) {
  // Reverse order here to prevent error.
  return knex.schema
  .dropTable('second')
  .dropTable('first');
}

Existe uma maneira de garantir que os arquivos de migração sejam executados em uma determinada ordem? Por exemplo, é uma prática ruim criar todas as minhas tabelas "regulares" em um arquivo e, em seguida, ter outro arquivo de migração para criar quaisquer tabelas de junção de que possa precisar?

Ou tudo isso deve ser feito no mesmo arquivo?

@LostCross pensa nos arquivos de migração como modificações em todo o esquema, não em uma única tabela.

por exemplo, o primeiro arquivo de migração deve definir o show inteiro.

se durante a vida do aplicativo houver um novo recurso e com ele algumas alterações no banco de dados, um novo arquivo de migração deve ser criado.

se você fizer assim, terá muito menos problemas do que dividir suas tabelas em vários arquivos.

Cada arquivo tem uma transação, então se você quiser sincronizar a execução de seus arquivos, você precisará mexer com seu pool de conexão para que a sequência seja garantida. Não é impossível, mas o esforço não compensa.