Improve upgrade CLI workflow

Problem

Today whenever you update the @prisma/cli package, you also need to update the @prisma/client package.

{
  "dependencies": {
    "@prisma/client": "2.7.0"
  },
  "devDependencies": {
    "@prisma/cli": "2.7.0"
  }
}

These two dependencies need to match. This is easy to forget for 2 reasons:

1. It’s unusual to have an implicit “peer dependency” on the Prisma Client.
2. You didn’t install the @prisma/client in the first place, it was added to the package.json for you by @prisma/cli

The upgrade flow is important for us because we’re releasing every 2 weeks right now. The more difficult it is to upgrade, the less people will upgrade. The less people that upgrade, the more we need to support older CLIs and Clients.

There are 2 ways to upgrade today:

# Install the new CLI
npm install @prisma/cli@latest @prisma/client@latest

# Check in the package.json that the version match up
cat package.json

# Generate new Client: 
npx prisma generate

# Run code
node index.js

Or

# Install the new CLI
npm install @prisma/cli@latest

# Remove old client from node_modules
rm -rf node_modules/@prisma/client

# Generate new Client
npx prisma generate

# Run code
node index.js

Note: This 2nd approach is more obscure, but slightly easier because it will update the @prisma/client automatically in your package.json.

Suggested solution

A good first step is to detect that there’s a mismatch between @prisma/client and @prisma/cli and fail (or warn?).

We also should consider calling this dependency what it is, a “peer dependency”. As an “ancient node-ster”, I instinctively recoil a little when I think of having “peer dependencies” in my app, so we’ll need to make sure expectations are set.

Alternatives

Run npx prisma update or npx prisma upgrade

Suggested by @williamluke4 😃

I could see this working too in the same way that npm upgrade npm works.

Auto-upgrade @prisma/client

I’d also like us to really think about auto-updating this dependency. Auto-upgrading would eliminate the need to detect a mismatch and always tie the @prisma/client to the @prisma/cli version that last generated the client.

We draw a clear line that we manage this dependency’s lifecycle. From creating, to updating, to perhaps deleting. We tell the user that they do not need to think or care about this package. As noted above, we do update this dependency automatically in certain circumstances. This might be a bug, but it does show that it works okay.

Where this can break down is when you have a global CLI and multiple projects. When you run generate with a newer CLI on an older project, it can cause a break. This problem seems bad, but feels like a non-issue to me in practice for a couple reasons:

1. The package.json’s @prisma/client version will tell you what CLI version you need. If you make this mistake it’s easy to fix.
2. Anecdotally, this is the status quo in the Go community today. While it seems like it should be a constant source of pain, in practice this issue almost never comes up. This makes me think, we shouldn’t optimize for this workflow of global CLI with many local installations.

I’d love to hear other folks thoughts on this too!

[timsuchanek]

Ok that’s a bug, here the “add prisma client” logic is going further than it should do.

[williamluke4]

How	Versions	Example
auto update	For Patches	2.4.0 ->2.4.2
prisma update	For minor versions	2.4 ->2.5
prisma upgrade	For major versions	1.34 -> 2.x