feat!: introduce accelerateUrl

[aqrln]

This PR introduces a new way to configure the Accelerate URL in preparation to removing url from PSL:

new PrismaClient({
  accelerateUrl: "prisma://...",
})

This property is mutually exclusive with adapter, and exactly one of them needs to be provided when using engineType = "client".

It also makes a few related changes along the way or as a side effect:

• Contributes towards TML-1459: the logic related to environment variables was completely removed from the RemoteExecutor code path, along with the resolveDatasourceUrl function.

• Fixes the @prisma/extension-accelerate extension which was inadvertently broken in feat(client): remove DataProxyEngine, remove /edge import #28345: while most of accelerateUtils (which were meant to be used by the removed AccelerateEngine) were indeed never used, one specific method is actually currently used: _accelerateEngineConfig.accelerateUtils.resolveDatasourceUrl. This PR now restores this function and re-implements it in a different way.

  • As a result of this, we now have a new validation and a DX improvement we didn't use to: now if you apply the Accelerate extension to a client that's not actually configured to use Accelerate, you will get a very clear error with a code suggestion.

• Removes null support for the adapter constructor option, which was introduced in feat(client): disallow explicit undefined value for adapter #21315. It was the only option that required null instead of undefined to disable it explicitly and it was inconsistent with the others. The motivation for introducing null and making it different from undefined made total sense for the LibraryEngine (where accidentally setting the adapter to undefined meant silently using completely different drivers before that change) but is now obsolete for the ClientEngine. Since we are removing LibraryEngine in feat(client): remove library engine #28375, we don't need this distinction anymore since there are no longer any pitfalls from using adapter: undefined, and removing it here in this PR made the validation around the combinations of adapter and accelerateUrl easier.

• Fixed the incorrect error message when Accelerate URL cannot be parsed.

Closes: https://linear.app/prisma-company/issue/TML-1507/env-less-accelerate-url-configuration

[github-actions]

size-limit report 📦

Path	Size
packages/client/runtime/library.js	145.66 KB (-0.54% 🔽)
packages/client/runtime/library.d.ts	112.72 KB (-0.9% 🔽)
packages/client/runtime/index-browser.js	2.23 KB (0%)
packages/client/runtime/index-browser.d.ts	3.28 KB (0%)
packages/cli/build/index.js	2.18 MB (+0.02% 🔺)
packages/client/prisma-client-0.0.0.tgz	11.33 MB (-0.13% 🔽)
packages/cli/prisma-0.0.0.tgz	9.49 MB (-0.1% 🔽)
packages/bundle-size/da-workers-libsql/output.tgz	848.48 KB (-0.06% 🔽)
packages/bundle-size/da-workers-neon/output.tgz	903.18 KB (-0.06% 🔽)
packages/bundle-size/da-workers-pg/output.tgz	895.14 KB (-0.06% 🔽)
packages/bundle-size/da-workers-planetscale/output.tgz	848.76 KB (-0.06% 🔽)
packages/bundle-size/da-workers-d1/output.tgz	831.4 KB (-0.06% 🔽)

[medz]

@aqrln Fantastic! I'm a Prisma accelerate user! This is exactly what I needed. The adapter was preventing me from switching to clientType = 'client'! With this, it means I only need const prisma = new PrismaClient({accelerateUrl: "..."})!

The current client adapter is extremely unfriendly to Prisma Postgres users! Not only are they forced to continue using prisma-client-js, but they also can't prepare for migrating to Prisma 7 in advance.

You're a superhuman! You've completely solved my pain points!

[aqrln]

@medz you can use Accelerate with engineType = "client" with Prisma 6 too, the way to do this is to not configure any driver adapter. It should work as long as the url property in the datasource block points at a prisma:// or prisma+postgres:// URL (alternatively, you can use datasourceUrl constructor option). But yeah, it's a little confusing.