Objection.js: Support for knex 0.95.0

[david-wb]

I just upgrade knex to 0.95.0 and now I'm getting typescript compilation errors in objectionjs like this:

node_modules/objection/typings/objection/index.d.ts:1830:12 - error TS2709: Cannot use namespace 'Knex' as a type.

1830     (knex: Knex, modelClasses: AnyModelConstructor[]): Promise<void>;
                ~~~~

Will support for 0.95 be added soon?

[koskimas]

Supporting 0.95 means dropping support for all versions before. Knex has put us in quite of a pickle. It's better to not update to 0.95 for now.

[kibertoad]

@koskimas I apologize for the problems caused by this change, but since we are starting to prepare for 1.0.0, it was important to lock in all the major breaking changes within 0.95.0 so that 1.0.0 is mostly uneventful with just last-minute lesser breaking changes included. And personally I find previous default exported type that could mean three different things, depending on a context, extremely confusing.
I take it that there are no plans for next Objection.js semver major in the nearby future?

[koskimas]

Well, objection should have limited the range of accepted peer dependencies to knex. You did bump the largest nonzero version with the breaking change, which is in line with semver. So knex did nothing wrong.

Objection used to have a strict selector for accepted knex versions, but then I had to bump that like every week when a new knex version came out, so I changed it to 0.x.

I don't want to bump the objection major version just for this though. I'll probably just bump the minor.

[kibertoad]

I'll update the PR for 0.95 support then.

[Zeswen]

If it's a breaking change, why wouldn't knex just go for 1.X.X?

[kibertoad]

@Zeswen You can only have one 1.0.0 release ever, so our decision was to do as many big changes in 0.95.0 as possible and work out all the rough edges, so that 1.0.0 is as polished and as attractive to the wide audience as possible. I expect it to have much lesser amount of breaking changes.

[Zeswen]

@Zeswen You can only have one 1.0.0 release ever, so our decision was to do as many big changes in 0.95.0 as possible and work out all the rough edges, so that 1.0.0 is as polished and as attractive to the wide audience as possible. I expect it to have much lesser amount of breaking changes.

Thank you for your clarification, but I believe a better approach would have been possible :)

As the semVer documentation implies, a pre-release 1.0.0-beta or 1.0.0-rc.1 would have been a great one for it.
Updating the minor versions breaks most of the packages that have automated minor/patch versions updates, its a great risk.

Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

[koskimas]

After giving it some more thought, I'll just go ahead and do "the right thing" and release 3.0. @kibertoad Are you sure there will be no more breaking changes before 1.0? Because if there will, We'll have to wait until that. I don't want to release 4.0, 5.0, 6.0 and 7.0 too just because of changes in knex.

[kibertoad]

@koskimas No more breaking changes in 0.95.0; next batch of breaking changes will be in 1.0.0, but hopefully none of them will be major enough to require changes on Objection side.

[kibertoad]

I'll update the 0.95.0 compatibility PR in a few hours, sorry for the delay

[koskimas]

@kibertoad Thank you so much for working on the PR. I really appreciate it!

next batch of breaking changes will be in 1.0.0

I'm afraid this means that we'll have to wait until 1.0 to release objection 3.0. I don't want to release 3.0 now to support > 0.95 < 1.0 and then 4.0 when knex 1.0 comes out 😞

[kibertoad]

@koskimas Honestly, I believe 1.0.0 breaking anything in Objection to be extremely unlikely. We've released 7 major versions of knex in last 2 years, and I think that 0.95.0 was the first one to include changes that ended up to be breaking for Objection. I think the extent of breaking changes in knex are going to amount to dropping deprecated use-cases such as passing negative offset, which Objection shouldn't care about. The whole idea of 0.95.0 was to do all the scary changes prior to 1.0.0.

[devinivy]

If the period of time is going to be relatively short between v0.95 and the release of v1, I'd recommend we just wait! What's the rush? Then objection v3 can support v0.95+, or if there do end-up being breaking changes between v0.95 and v1 that affect objection, perhaps objection would just skip v0.95 or be able to offer some compatibility option. I don't see any major downside, besides not being able to use v0.95 immediately which sounds like it's being used as a beta version of v1 anyway, and the upside is that objection users are protected from potential churn and confusion. I feel pretty sure that if it had been released as a v1 beta, that is how it would be approached on the objection side. Another option is to release an objection v3 alpha with support for knex v0.95. I have been following this conversation closely, as I maintain schwifty which is a peer of objection.

[kibertoad]

I doubt it's going to be short. My current estimate would be half a year to a year till 1.0.0.

[vladaman]

@devinivy We are starting new project, which combination of versions would you suggest to use?

[koskimas]

@vladaman The newest objection version supports knex < 0.95. So I'd use the latest objection and the highest knex < 0.95

[vladshcherbin]

According to previous knex 1.0 plans, it's reasonable to release 0.95 support in 3.0.
Knex major release may happen in a few years and it'll be nice to use 0.95 in objection until then.

[koskimas]

Was there something critical released with knex 0.95? Is there a compelling reason for people to update to knex 0.95? If there were no major bug fixes or new features, I don't see the point in releasing 3.0 just for 0.95 - 1.00 and I agree with @devinivy that we should just wait.

[kibertoad]

@koskimas There were drastic improvements to MSSQL support and plenty of new stuff for SQLite, and overall it was probably the most improvement-packed major version in the last three years.
If that would make you more comfortable to release 3.0 earlier, I can personally promise that there will be no changes that would be breaking for Objection.js in 1.0.0, and if there end up being any, I would revert them.

[koskimas]

@kibertoad Sounds great! Thank you. I'll move forward with the release of 3.0 then.

[JaneJeon]

Ohhhhh, sh*t, things are happening! @koskimas is Objection3 going to be just a semver update to accomodate knex0.95/1 or do you see making other breaking changes as well (or using this opportunity to add/drop some features)?

[kibertoad]

There were at least two other breaking changes mentioned that are likely to be included in this window as well.

[JaneJeon]

@kibertoad for knex or objection3?

[kibertoad]

Objection. To quote koskimas:
"I'll also get the chance to fix #1651 and #1689 at the same time, both of which require breaking changes."

[anish-techpro]

Sounds great! Thank you. I'll move forward with the release of 3.0 then.

@koskimas what is the ETA for objection 3.0? and should we continue development with the following combination as of now?

"knex": "^0.95.2",
"objection": "^2.2.15"

[devinivy]

@anish-techpro my understanding is that we should stick with knex v0.21 when using objection v2. This is now reflected in objection's peer dependencies. Once objection v3 is released then knex 0.95 and eventually knex v1 will be on the table.

[koskimas]

@AnianZ There's no ETA unfortunately. It'll happen when I find couple of days of spare time to do work on objection.