What's next for KeystoneJS

[bladey]

Keystone 5 has officially moved into active maintenance mode as we push towards the next major new version of KeystoneJS.

What's next?

When Keystone 5 was announced in 2018, it was a great leap forward for the project from a back-end Node.js CMS platform built with MongoDB, to a modern platform with first class support for GraphQL, PostgreSQL, and more.

Keystone Next is a preview of the next major release of KeystoneJS, the most powerful headless content management system around. We've substantially rewritten the CLI, Schema config, and Admin UI to make them more powerful and easier to use than ever before.

In the last six months, we built around the existing stable core of Keystone 5's packages to test the changes we wanted to make and validate our ideas. We're now happy with what we've built, and over the course of this year, Keystone Next will become Keystone 6.

There is a lot to do, and with a larger than ever team at Thinkmill working on it, we're excited to show you what we're planning and get it shipped!

You can learn more about the next version, which is now in preview.

What happens to Keystone 5?

The Keystone 5 codebase is now in active maintenance mode and now lives at keystonejs/keystone-5.

What does maintenance mode entail?

• You can generally expect Keystone 5 to be feature-frozen as we work on the new version.
• Bugs, minor changes and security features will continue to be addressed and updated versions of the Keystone 5 packages will continue to be released regularly.
• The core team is not expecting to spend time working on new features or large changes.
• If you have a larger change you want to submit as a PR to Keystone 5, feel free to open an issue to discuss it with us.
• We are not closing the door to community-contributed features through the maintenance period, but depending on the scope of the change and the work involved we may suggest maintaining your own fork.
• The duration of this active maintenance mode will depend on community adoption of the new version of Keystone, and how long it takes us to reach feature parity and stability with Keystone Next.
• We expect this active maintenance mode to last for 6 to 12 months.

What about open PRs and Issues?

We’ll be cleaning up old issues and PRs in this repo in the coming weeks, so that we only have things relating to the new Keystone Next codebase.

If you have a PR or Issue relating to Keystone 5, please open it in our new repo.

Thank you for your continued support as we push towards this next major new version of KeystoneJS!

[anup-a]

@bladey Hi, I'm planning to build an app using keystone and just noticed that it will be migrate to keystone next.

What things would you suggest to keep in mind, so that it would be easy upgrade from version 5 to 6?

Would it have significant breaking changes (syntax wise), if decided to migrate from keystone 5 to 6?

[chrisschaub]

We are on keystone v4, and have started an upgrade to v5. Or should we just go straight no next? Thanks.

[JedWatson]

At this point, it's hard to give a firm recommendation, both approaches have pros and cons that I'll do my best to outline.

Personally I think the best outcome is if you can go with keystone-next (the Keystone 6 preview). We're putting almost all our focus on developing it and it's improving every week.

There are a few major things that will change between 5 and 6 which we are currently transitioning in Next:

• New field types, including the new Document field (which replaces the old Content field)
• New configuration syntax and CLI
• New express-independent session system
• New internal APIs for querying lists
• Completely new Admin UI

We're also transitioning from maintaining several database adapters to just using Prisma which simplifies things quite a bit, but means that until Prisma support MongoDB (which is planned) we'll have a gap in our database support. There are also differences between knex and Prisma for Postgres users, which mainly matter for advanced use cases like migrations and raw sql, etc.

Thinkmill is already running Keystone Next in production (including for rugby.com.au) so we do rate it as stable from a runtime perspective; but from an API perspective it is still evolving fairly regularly.

---

Having said that, it really depends on the requirements for your project. If you need more battle-tested foundations, Keystone 5 would be the answer today.

Also, we've stripped back quite a few field types and some other functionality during the transition from 5 to 6, which will be coming back but we're not at feature parity yet. This includes fields like the File field, HTML fields, etc. They aren't far off in Next, but right now if you need something urgently that Next doesn't include then that might answer the question for you.

The other major consideration is how much you need a stable API to build on, how much time you want to spend keeping up with changes as we build out the Next packages vs. leaving a big upgrade for later (Keystone 5 to 6). Also how important it is that you have comprehensive documentation. We've now published docs for most of the APIs in keystone next, but there's still a lot we have yet to write.

Transitioning projects from Keystone 5 to 6 will be possible, but it won't be a simple process of tweaking the configuration. You'd be rewriting your config, schema, session and access control functions, at a minimum. We're hoping not to make it hard -- the sort of thing you can do in a day or two, as you're fundamentally configuring the same things, but it'll be quite different.

Here's the current comparison:

Keystone Next

Pros

• Latest and greatest. We're really excited about the new stuff we're doing, and a lot of the system is already much better than Keystone 5
• Awesome new document field, slightly less complete but generally better Admin UI
• Rapidly getting better, more modern foundations
• Easier to deploy with database migrations (coming this week)
• As long as you can keep on top of the updates, you'll not hit a major upgrade wall for quite a while

Cons

• You'll need to keep on top of changes as we keep evolving keystone next into a more complete and stable API
• Docs aren't comprehensive yet
• Less battle tested (we have spent a lot of effort bringing our entire test suite forward and keeping it green, but there will always be things we could miss this early on)
• You should only use Postgres as the database back-end at this point (personally that's not a con for me, but worth calling out it may be for some)

Summary: this is the choice I would personally make, but it's a high level of responsibility to take

Keystone 5

Pros:

• Stable, well documented, battle tested. There are some rough edges for sure, but at this point it's very clear where they are.
• Not going to change much going forward, so your codebase will also be stable. No API churn.
• More comprehensive features (for example, more field types at this point that keystone next)

Cons:

• It won't be changed much going forward, so it's very much "use it if it works for you" at this point
• You'll have a moderate rewrite ahead of you to upgrade to keystone 6 if you want the new stuff
• If you're starting from scratch with a project, it's more complex to configure and (aside from next docs being incomplete) imo harder to learn

---

I hope this helps! let us know if you have any other specific questions and we'll do our best to answer them.

[gautamsi]

Also, we've stripped back quite a few field types and some other functionality during the transition from 5 to 6, which will be coming back but we're not at feature parity yet. This includes fields like the File field, HTML fields, etc. They aren't far off in Next, but right now if you need something urgently that Next doesn't include then that might answer the question for you.

for anyone interested, there is contrib project which may provide the missing fields with bare minimum feature support from v5 here - https://github.com/keystonejs-contrib/keystonejs-contrib/tree/master/packages-next also look at PRs - https://github.com/keystonejs-contrib/keystonejs-contrib/pulls specially keystonejs-contrib/keystonejs-contrib#17 which is final just waiting for some more real world testing.

if you work on any field and make it compatible with v6, feel free to open a PR to contrib repo

[JedWatson]

Good point @gautamsi and thanks for sharing those links! the contrib project has some great polyfills for anyone who needs something we haven't brought forward yet.

[chrisleyva]

Hello, I am following the How to embed Keystone + SQLite in a Next.js app guide and I'm loving it. Very straight-forward.
Now that I have completed the guide, I wanted to build & add to it when I noticed quite a few fields are missing from @keystone-next/fields. For example, CalendarDay. Is this known? Or will this field be going away in the future release?

Thank you for your hard work.

UPDATE
Sorry, I just came across the section in your docs which I think explains the issue. I'm assuming CalendarDay will come back soon?