…This happens because you removed “Bluebird” dependency and returns a pure promise instead. This should have been a major change probably.

Yes that will work @briandamaged, but changing my code anyways it makes more sense to just adopt async/await style anyways.

But as @skreis points out your documentation kind of documents a bluebird like API.

Have you considered adopting a more “semver” like versioning? The current change is kind of dangerous as most people will use the "knex": "^0.20.0" syntax in their package.json and documented usages of the knex library breaks with the 0.20.11 release. Most npm user get it automatically because one expect patch releases to not change APIs.

Any reason you are not ready to move towards a “1.0.0” release?

Anyways thanks for all the great work with knex, it has severed me well for many years!

Howdy, and sorry about that!

We actually were debating quite a bit about whether or not this should be a major release. We ultimately decided to treat it as a minor release because the knex documentation did not officially claim to support the Bluebird interfaces. (ie: the interfaces were simply leaked due to the way the code was structured).

In either case, you can make the interfaces available again by wrapping the knex calls with Bluebird.resolve(..). For example:

// Split onto multiple lines for readability
Bluebird.resolve(
  this.db.select(...).from(...).limit(...).whereRaw(...).orderBy(...)
).map

If someone looking for a quickfix:

from:

exports.seed = async knex => {
  const data = await knex
    .select('id')
    .from('table')
    .map(({ id }) => id)
}

to:

exports.seed = async knex => {
  const data = (await knex
    .select('id')
    .from('table')).map(({ id }) => id)  
}

@elhigu So you would be in favour of making next major release (when we drop Node 8 and potentially change some of pooling logic that @briandamaged is cooking up now) the 1.0.0?

@ungrim97 Good point about documentation part, will do.

@kibertoad Nod. It is what it is. I am mostly salty right now cause I have just spent the day trying to work out why my application fell over when I hadn’t made any real change here.

As I said I can understand why, though I personally feel that bluebird fixes some specific lacking features and implementation designs over native promise.

For me I was using the .map shorthand provided by bluebird as this has both concurrency support and saves doing .then(results => results.map((result) => { thingWithResult(result)}));

I suppose interoperability with Native Promises and async/await won out.

I would recommend doing something similar to sinon and adding a usingPromise method that allows the user to set a Promise implementation onto their promise chain.

Also I would suggest adding a big notice to the top of the Documentation as that would have saved me several hours of debugging

Yeah. So this change just massively broke a bunch of my applications. Thanks for that.

I can understand the rational behind wanting to not use Bluebird. But this was absolutely a breaking change and should very much have been a major version change. Even if the interface wasn’t documented, it is clear that people have come to use it.

But yeah, not everyone knows what Bluebird means in this context and were just confused that certain methods went away; and warning wasn’t big and scary enough; and actually scary breaking changes came later. Yes.

@elhigu I agree. Though I suppose these weren’t deemed as breaking changes originally as the interface wasn’t documented as supporting the features being used.

This is one of those Bug becomes a Feature. Is fixing a bug a breaking change…Depends on who is relying on the bugs behaviour