Code Monkey home page Code Monkey logo

node-migrate's Introduction

Migrate

NPM Version NPM Downloads JavaScript Style Guide Build Status

Abstract migration framework for node.

Installation

$ npm install migrate

Usage

Usage: migrate [options] [command]

Options:

  -V, --version  output the version number
  -h, --help     output usage information

Commands:

  init           Initalize the migrations tool in a project
  list           List migrations and their status
  create <name>  Create a new migration
  up [name]      Migrate up to a given migration
  down [name]    Migrate down to a given migration
  help [cmd]     display help for [cmd]

For help with the individual commands, see migrate help [cmd]. Each command has some helpful flags for customising the behavior of the tool.

Programmatic usage

var migrate = require('migrate')

migrate.load({
  stateStore: '.migrate'
}, function (err, set) {
  if (err) {
    throw err
  }
  set.up(function (err) {
    if (err) {
      throw err
    }
    console.log('migrations successfully ran')
  })
})

Creating Migrations

To create a migration, execute migrate create <title> with a title. By default, a file in ./migrations/ will be created with the following content:

'use strict'

module.exports.up = function (next) {
  next()
}

module.exports.down = function (next) {
  next()
}

All you have to do is populate these, invoking next() when complete (no need to call next() if up/down functions are async), and you are ready to migrate!

For example:

$ migrate create add-pets
$ migrate create add-owners

The first call creates ./migrations/{timestamp in milliseconds}-add-pets.js, which we can populate:

// db is just an object shared between the migrations
var db = require('./db');

exports.up = function (next) {
  db.pets = [];
  db.pets.push('tobi')
  db.pets.push('loki')
  db.pets.push('jane')
  next()
}

exports.down = function (next) {
  db.pets.pop('pets')
  db.pets.pop('pets')
  db.pets.pop('pets')
  delete db.pets
  next()
}

The second creates ./migrations/{timestamp in milliseconds}-add-owners.js, which we can populate:

var db = require('./db');

exports.up = function (next) {
  db.owners = [];
  db.owners.push('taylor')
  db.owners.push('tj', next)
}

exports.down = function (next) {
  db.owners.pop()
  db.owners.pop()
  delete db.owners
  next()
}

Advanced migration creation

When creating migrations you have a bunch of other options to help you control how the migrations are created. You can fully configure the way the migration is made with a generator, which is just a function exported as a node module. A good example of a generator is the default one shipped with this package.

The create command accepts a flag for pointing the tool at a generator, for example:

$ migrate create --generator ./my-migrate-generator.js

A more simple and common thing you might want is to just change the default template file which is created. To do this, you can simply pass the template-file flag:

$ migrate create --template-file ./my-migration-template.js

Lastly, if you want to use newer ECMAscript features, or language addons like TypeScript, for your migrations, you can use the compiler flag. For example, to use babel with your migrations, you can do the following:

$ npm install --save babel-register
$ migrate create --compiler="js:babel-register" foo
$ migrate up --compiler="js:babel-register"

Running Migrations

When first running the migrations, all will be executed in sequence.

$ migrate
  up : migrations/1316027432511-add-pets.js
  up : migrations/1316027432512-add-jane.js
  up : migrations/1316027432575-add-owners.js
  up : migrations/1316027433425-coolest-pet.js
  migration : complete

Subsequent attempts will simply output "complete", as they have already been executed. migrate knows this because it stores the current state in ./.migrate which is typically a file that SCMs like GIT should ignore.

$ migrate
  migration : complete

If we were to create another migration using migrate create, and then execute migrations again, we would execute only those not previously executed:

$ migrate
  up : migrates/1316027433455-coolest-owner.js

You can also run migrations incrementally by specifying a migration.

$ migrate up 1316027433425-coolest-pet.js
  up : migrations/1316027432511-add-pets.js
  up : migrations/1316027432512-add-jane.js
  up : migrations/1316027432575-add-owners.js
  up : migrations/1316027433425-coolest-pet.js
  migration : complete

This will run up-migrations up to (and including) 1316027433425-coolest-pet.js. Similarly you can run down-migrations up to (and including) a specific migration, instead of migrating all the way down.

$ migrate down 1316027432512-add-jane.js
  down : migrations/1316027432575-add-owners.js
  down : migrations/1316027432512-add-jane.js
  migration : complete

Any time you want to see the current state of the migrations, you can run migrate list to see an output like:

$ migrate list
  1316027432511-add-pets.js [2017-09-23] : <No Description>
  1316027432512-add-jane.js [2017-09-23] : <No Description>

The description can be added by exporting a description field from the migration file.

Custom State Storage

By default, migrate stores the state of the migrations which have been run in a file (.migrate). But you can provide a custom storage engine if you would like to do something different, like storing them in your database of choice. A storage engine has a simple interface of load(fn) and save(set, fn). As long as what goes in as set comes out the same on load, then you are good to go!

If you are using the provided cli, you can specify the store implementation with the --store flag, which should be a require-able node module. For example:

$ migrate up --store="my-migration-store"

API

migrate.load(opts, cb)

Calls the callback with a Set based on the options passed. Options:

  • set: A set instance if you created your own
  • stateStore: A store instance to load and store migration state, or a string which is a path to the migration state file
  • migrations: An object where keys are migration names and values are migration objects
  • migrationsDirectory: The path to the migrations directory
  • filterFunction: A filter function which will be called for each file found in the migrations directory
  • sortFunction: A sort function to ensure migration order

Set.up([migration, ]cb)

Migrates up to the specified migration or, if none is specified, to the latest migration. Calls the callback cb, possibly with an error err, when done.

Set.down([migration, ]cb)

Migrates down to the specified migration or, if none is specified, to the first migration. Calls the callback cb, possibly with an error err, when done.

node-migrate's People

Contributors

aheckmann avatar akivajgordon avatar awbush avatar danielpza avatar dguo avatar epiccoolguy avatar ericsaboia avatar igor-lopes avatar joaosa avatar joshua-elminda avatar kishorenc avatar koenpunt avatar konard avatar krishna-atkalikar avatar limianwang avatar linusu avatar luisrudge avatar mayankbatra avatar mikesglitch avatar okorolko avatar polad avatar rmarscher avatar rundef avatar ryanrolds avatar simison avatar tj avatar tmikeschu avatar wesleytodd avatar woodz avatar zebulonj avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

node-migrate's Issues

setup/teardown

Plz, add setup/teardown functions to open/close db connection before/after couple of migrations

The framework does not recognize a Bluebird Promise

Hey โ€” I've been this library for some time (in particular the next version) and so far it has been working great, thanks.

Now, I'm in a migration where for some reasons the promises being returned from the code aren't native from Node, but rather from Bluebird.

Therefore node-migrate does not recognize them (as they're not instanceof Promise) and switches back to callbacks, that aren't provided of course.

It would be good if it could work with Bluebird promises as well and more importantly, if no async mechanism is detected, a warning could be shown.

Thanks!

Feature Request: Set Options Via Environment or .migraterc File

There may be a better way to accommodate this, so let me frame it in terms of a use-case...

I'm storing state in a database (using the --store option to designate) have migrations in a non-standard location (--migrations-dir=...) and have written my migrations in ES6 (--compiler=...), but it's a pain to specify all those command-line options every time I run migrate[1].

It'd be nice to be able to specify those options in a per-repository .migraterc file or via environment (managed by other means) on each repository.

[1] I initially solved this by adding a migrate:up script to my package.json, but as my needs become more complex that isn't cutting it. I've run into problems using package.json scripts to handle rolling pack individual migrations, etc.

Save after each migration

Currently it seems that migrate only saves to the state-file after the last migration is done. If an error occurs during any migration, the file dosen't get updated at all.

This can be a problem if I have three migrations to run, and only the last one fails. If I fix it and then run migrate up again, it will run the former two again, possibly resulting in more errors.

v1 does not respect old migration state file format

When running migrations with a pre-v1 migration state file in v1, migrate ignores the old format and attempts to run all migrations in the migration directory. which is poor behavior. If the format of the file is not what is expected it should error, otherwise the database is at risk of being placed in an invalid state. Consuming and migrating the old format to the new format may be preferred.

use with mongoose?

Can I use mongoose inside my up and down?

Also, I need to do some data transformation on my database in dev, test and prod.
Is there a way to run this migration script against a different environment?

Down migrate incrementally

It would be useful to have an option to migrate down or up incrementally, with the ability to specify the migration to go to. For example, say I have 15 migrations, and would need to rollback the last two migrations, I can just say something like:

e.g. migrate down 12-migration-title.js

Right now, migrate down cascades all the way till all down migrations are done.

Consider using timestamps instead of migration numbers

I remember when RoR migrations were using numbers instead of timestamps and it was a mess.

Bob: creates migration 1-do-nasty-stuff
Alice: creates migration 1-remove-foo
Richard: pulls Bob's and Alice's changes. Pain.

first migrate create not running

Running migration like so:

migrate create anamehere

Raises error:

migrate: error: Not enough arguments for command create: name not specified
ubuntu@ip-172-31-19-221:~/statblender$ migrate create
Usage: migrate create REPOSITORY_PATH NAME [--table=TABLE]

Just installed on ubuntu via:

npm install migrate

Error running "down" command twice

If I run "down" command twice. First time, it executes all migrations in reverse order and the second time it executes first migration, after that it always shown complete message.
Running "up" command after this, causes that first execution perform last migration and then in a second execution it runs all migrations in order.

Is this a normal behavior? Is there a way to rid of this problem?

Thank you in advance.

file extension of migration created by migration create should match template

Scenario:
I created with migration_template.ts with contents

export const up = next => {
  next()
}

export const down = next => {
  next()
}

and ran yarn migrate create --template-file ./migration_template.ts.

Expected:
migration file in migrations directory is created with .ts extension

Actual:
migration file in migrations directory is created with .js extension

Support for 0.6.0

I don't want to cause more work for you but, migrate and a few others are not supporting 0.6.0. I know it was just released; take your time. I just wanted to create issues. If you want I can fork and help with the migrations.

`migrate` is also used in rake

I just installed this package. Looks great but the command line command migrate is also used by rake, if I run which migrate I get the following:

migrate: aliased to rake db:migrate && rake db:test:prepare

Maybe this could be noted somewhere or solved in some way.

The framework does not work when used with Promise.all

In case you're returning Promise.all([]) instead of a single promise, the return value is an array instead of an object.

In case all the promises are resolved correctly, the return value is [undefined,undefined,undefined].

This is clashing with this part that requires the error object to be undefined.

The catch handler should probably be a different one than the completion handler, so we do not incur in these situations.

I can provide a PR if you appreciate.

Maintainer

@tj I understand that you no longer maintain your Node.js projects and I was wondering if you would be interested in adding me as a collaborator to this repo. I have no plans for any drastic changes but I would like to ensure stability and close some of the bugs that are currently open. Thanks for your time.

My first order of business would be to merge in #47, #48, #49 and make sure that we can release them without any backwards-incompatible changes.

I'm linusu on npm.

Store state in the DB, not in a file.

Storing the state of which migrations have been run in the DB itself, rather than in a file may be preferable in a number of circumstances:

  • Running large clusters
  • Running phoenix servers

The trouble with a local file, is you pin your migrations to that machine (or you need to copy the file around). This may not always be possible in some setups. It would be good (as in rails activerecord migrations framework) to be able to store the DB state in the database itself, perhaps via a flag to the migrate command or something like that.

Migrate doesn't recognize latest migration.

Running on a Digital Ocean Droplet - (Linux)

Created a migration with migrate create command.
Running "migrate" or "migrate up" just shows complete. Should create a log file in our setup (from within migration script) as well which doesn't exist.
Running migrate up with the individual migration file throws an error.

screen shot 2015-07-09 at 2 13 28 pm

Idea: Special force clean migration

I often find myself manually dropping tables because I am making a new migration and have an error in it which my down does not or cannot compensate for. In development I really want just a nuclear option which is more forceful than migrate up --clean in that it does not run all the down's, but instead it a full "drop all tables" kind of migration.

So my thought is that we add a special exception for clean.js which would be run instead of all the down's if it exists on --clean. It would of course need to be manually maintained and edited as you add migrations, but it would be a bit more simple to maintain than having all of the down's work in all situations.

What do people think of this idea?

cc: @LinusU @joaosa @tj

down() doesn't revert failed up()

Let's say you have 2 migrations:

  • migration-a.js (migrated successfully)
  • migration-b.js

When migration-b fails in up() and you try to recover state calling set.down('migration-a') then you revert changes from migration-a. If you try to exececute set.down('migration-a') then down() is not called.

I believe that down() shall correct errors after an unsuccessful up() from the same file. Is there a way how to achieve it or do we have to implement it?

Cannot create migration scripts as cwd is never defined.

Will add a pull request for this.

Issue can be fixed with the following code to the create function:
cwd = cwd || process.cwd();

Exception:
path.js:204
throw new TypeError('Arguments to path.join must be strings');
^
TypeError: Arguments to path.join must be strings
at f (path.js:204:15)
at Object.filter (native)
at exports.join (path.js:209:40)
at create (C:\Users\darren.haken\AppData\Roaming\npm\node_modules\migrate\bin\migrate:199:17)
at Object.commands.create (C:\Users\darren.haken\AppData\Roaming\npm\node_modules\migrate\bin\migrate:176:5)
at Object. (C:\Users\darren.haken\AppData\Roaming\npm\node_modules\migrate\bin\migrate:239:9)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)

middleware -- reatltime

Hi TJ, have you created a way to integrate this into a web app module, so that when the server is restarted, deployed, etc, a middleware is triggered to run these? I am using a host called modulus.io where you dont have SSH access to the server.

Just curious before I go and build one.

Governance?

@LinusU & @joaosa

It looks like you two are the most "recent" large contributors. Before I move forward, can you let me know what level of involvement you would like to have with moving forward? I would be down with coming up with some guidelines/process if you want to be involved. Or I can just take over and move it in the direction which my fork has been going, which adds features and in some cases breaks current functionality. Let me know!

Can't migrate on Windows

I have set of migrations which works perfectly on linux systems, but when I try to run migrations on Windows machine I get the following:

{ProjectPath}>yarn run migrate
yarn run v1.2.1
$ node -r dotenv/config node_modules/.bin/migrate --state-file runtime/.migrate
{ProjectPath}\node_modules\.bin\migrate:2
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
          ^^^^^^^

SyntaxError: missing ) after argument list
    at createScript (vm.js:80:10)
    at Object.runInThisContext (vm.js:139:10)
    at Module._compile (module.js:588:28)
    at Object.Module._extensions..js (module.js:635:10)
    at Module.load (module.js:545:32)
    at tryModuleLoad (module.js:508:12)
    at Function.Module._load (module.js:500:3)
    at Function.Module.runMain (module.js:665:10)
    at startup (bootstrap_node.js:187:16)
    at bootstrap_node.js:608:3
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

This is migrate script command:

"migrate": "node -r dotenv/config node_modules/.bin/migrate --state-file runtime/.migrate",

Feature Request: make node-migrate aware of NODE_ENV

It will be cool if migrations could be recorded per deployment environment. So, if I run them locally, the .migrate file is going to include "development" somewhere. And once I deploy onto staging or production, my migrations could run again and I will be able to version .migrate as well. Does this make sense? Is there any other way to make sure migrations don't get executed several times upon deployments onto production or staging?

Usage from code

It seems to me like much of the code is in bin/migrate file and it isn't as straight forward as it could be to call migrate from other nodejs code.

Also, migrate works with a singelton and calling one function multiple times with different arguments. This seems to me like a quite poor api design.

I think it would be awesome if I could use migrate something like this:

var migrate = requrie('migrate');

function cb(err) {
  if (err) throw err;
  console.log('Success!');
}


// Up
migrate.load('migrations/.migrate', 'migrations/*.js').up(cb);

// Run only one migration
migrate.load('migrations/.migrate', 'migrations/*.js').up(1, cb);


// Down
migrate.load('migrations/.migrate', 'migrations/*.js').down(cb);

// Revert only one migration
migrate.load('migrations/.migrate', 'migrations/*.js').down(1, cb);


// Create
migrate.load('migrations/.migrate', 'migrations/*.js').create('add email to user', cb);

// Create with file content
var content = 'throw new Error("Not implemented");';
migrate.load('migrations/.migrate', 'migrations/*.js').create('add email to user', content, cb);

Any thoughts?

The program 'migrate' can be found in the following packages

Hello, guys, I'm trying to run this migrate command migrate create add-pets but the problem is it is throwing me an error pointed out int the above title. I have installed it using yarn

yarn add migrate

but whenever I try to run the command it is throwing me the above error

OS: UBUNTU

Use with mongoose any examples?

I am struggling to make mongoose work with node-migrate .
I am trying to use mongoose inside my up and down of migration script.
However callback for a simple find query never get executed e.g.
I have an existing User model (users collection with pre-existing documents)
Here's how my up function looks like

exports.up = function(next) { 
var mongoose = require('mongoose');
var User= require('./somepath/user');
mongoose.connect(<dbUrl>); 

  User.find().exec(function(err,
    users) {
  next(); //this never get executed??
  });
}

I tried wrapping query inside mongoose.connection.on('connected') e.g.

mongoose.connection.on('connected', function() {
     User.find().exec(function(err, users) {
    next(); //this never get executed??
  });
});

But still callback does not gets executed.

Any help would be appreciated.

Removing old migrations causes confusion

Removing old migration files seems to bring node-migrate out of sync. Example:

$ migrate create one
$ migrate create two
$ migrate create three
$ ls migrations
1510670884434-one.js   1510670888566-two.js   1510670890981-three.js
$ migrate
  up : 1510670884434-one.js
  up : 1510670888566-two.js
  up : 1510670890981-three.js
  migration : complete

Later we add a new migration and remove old ones, which we do not want to support any longer:

$ migrate create four
$ ls migrations
1510670884434-one.js   1510670888566-two.js   1510670890981-three.js 1510670980407-four.js
$ rm migrations/1510670884434-one.js migrations/1510670888566-two.js
$ ls migrations
1510670890981-three.js 1510670980407-four.js
$ migrate
  migration : complete

Notice that 1510670980407-four.js will not get executed now.

In our case, we would like to remove old migration scripts, because their logic wouldn't work any longer anyways due to changed dependencies, etc.

This happens with 0.2.4 and the version from the next tag as well. Is this behavior intentional or could be handled more gracefully in the future?

Missing migration file

I'm working with a distributed team on an application that depends on node-migrate, but we're running into an issue when we switch from a feature branch back to master (which is missing the migration(s) from the feature branch).

$ git init
Initialized empty Git repository in /home/christianbundy/work/node-migrate-repro/.git/
$ echo ".migrate" > .gitignore
$ migrate --version
1.1.1
$ migrate init
  migrations dir : /home/christianbundy/work/node-migrate-repro/migrations
$ migrate create a
  create : /home/christianbundy/work/node-migrate-repro/migrations/1515783157036-a.js
$ migrate up
  up : 1515783157036-a.js
  migration : complete
$ git add -A
$ git commit -m "Initial commit"
[master (root-commit) aca1d14] Initial commit
 2 files changed, 10 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 migrations/1515783157036-a.js
$ git checkout -b new-feature
Switched to a new branch 'new-feature'
$ migrate create b
  create : /home/christianbundy/work/node-migrate-repro/migrations/1515783180837-b.js
$ migrate up
  up : 1515783180837-b.js
  migration : complete
$ git add -A
$ git commit -m "New feature"
[new-feature 2bd3e51] New feature
 1 file changed, 9 insertions(+)
 create mode 100644 migrations/1515783180837-b.js
$ migrate down
  down : 1515783180837-b.js
  down : 1515783157036-a.js
  migration : complete
$ git checkout master
Switched to branch 'master'
$ migrate up
  error : Error: Missing migration file: 1515783180837-b.js

asciicast

I imagined that migrate down would remove the state file after a successful down migration, but it looks like it's still keeping track of all of the previous migrations (even though they've been taken down). Is there a better way of doing this?

Thanks so much for your work on this project!

Use Typescript as compiler

Hi everyone,

Is there an example usage of typescript as compiler? I already tried different suggestions from my question here in stackoverflow but with no luck.

Any help is much appreciated ๐Ÿ˜„

Create not creating migration

I am running:
$ node migrate create setup

No setup file is created. I have also tried with -c and --chdir with no luck.

Wondering if this does not work in node v 0.10.x

Test no longer works

It seems like the code has been updated without running the tests after. The tests expects set.up to take a callback, but it dosen't.

The documentation for the function still acts like it does though:

/**
 * Run up migrations and call `fn(err)`.
 *
 * @param {Function} fn
 * @api public
 */

Set.prototype.up = function(migrationName){
  this.migrate('up', migrationName);
};

Uncaught Error: Cannot find module "." when using Webpack and programmatic usage

Hi, thanks for maintaining this great repo. I'm very optimistic it will fill an important need I have.

I'd like to manage migrations in an Electron app releases using node-migrate. I got command line usage working fine, but am having an issue where node-migrate can't load my migrations files. My app uses Electron, ES6, and Webpack (it's based on electron-react-boilerplate)

My code:

  nodeMigrate() {
    log.info('Starting migrations');

    // TODO: Update path for production
    const stateStore = path.join(process.cwd(), '.migrate');
    const migrationsDirectory = path.join(process.cwd(), 'migrations');

    log.info(`stateStore ${stateStore}`);
    log.info(`migrationsDirectory ${migrationsDirectory}`);

    const migrateConfig = {
      stateStore,
      migrationsDirectory,
    };

    migrate.load(migrateConfig, (error, set) => {
      if (error) {
        log.error(`Failed to load migrate config: ${error}`);
        throw error;
      }

      set.up((error) => {
        if (error) {
          log.error(`Running migrations failed: ${error}`);
          throw error;
        }
        log.info(`Migrations successfully ran!`);
      })
    });
  }

The log messages indicate the correct directories:

[14:45:24.307] [info] stateStore /Users/ben/code/tesla/.migrate
[14:45:24.307] [info] migrationsDirectory /Users/ben/code/tesla/migrations

When the migrations run, I get this error:
developer_tools_-_file____users_ben_code_tesla_app_app_html

Digging into the stacktrace, the code that has been executed in my environment is:

      // Create migrations, keep a lookup map for the next step
      var migMap = {}
      var migrations = files.map(function (file) {
        // Try to load the migrations file
        var mod
        try {
          mod = !(function webpackMissingModule() { var e = new Error("Cannot find module \".\""); e.code = 'MODULE_NOT_FOUND'; throw e; }())
        } catch (e) {
          return fn(e)
        }

        var migration = new Migration(file, mod.up, mod.down, mod.description)
        migMap[file] = migration
        return migration
      })

The code as it's written in this repo is:

      // Create migrations, keep a lookup map for the next step
      var migMap = {}
      var migrations = files.map(function (file) {
        // Try to load the migrations file
        var mod
        try {
          mod = require(path.join(migrationsDirectory, file))
        } catch (e) {
          return fn(e)
        }

        var migration = new Migration(file, mod.up, mod.down, mod.description)
        migMap[file] = migration
        return migration
      })

It seems that at compile time, Webpack (or Babel?) is attempting to rewrite the require() and it fails.

After doing some digging, I think it might be because the require() as written in the code uses an expression instead of a value. See this: webpack/webpack#4921 (comment)

My instinct would be to create a PR that changes:

mod = require(path.join(migrationsDirectory, file))

to

mod = require(`${path.join(migrationsDirectory, file)}`)

(this solution) but this project itself isn't written in ES6.

Any direction you could provide on getting node-migrate working nicely with Webpack would be much appreciated. I'm not well-versed on require/import in JavaScript, and how it impacts require(), but I expect it's some misalignment of expectations between Webpack and node-migrate.

Thanks for your time. ๐Ÿ™

Only run one down migration by default.

It seems like it would be a more sensible default to only run the most recent "down" migration when running "migrate down". Perhaps I just haven't thought enough into this, but I don't know a time when I would ever want to run a full teardown. It would seem to be much more reasonable just to roll back the most recent migration when running "migrate down", and maybe have a new keyword when you want to roll back every migration.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.