Hum sadly zod does not make it possible to differentiate { id: 'my-id', firstName: 'Jon' } and { id: 'my-id', firstName: 'Jon', lastName: undefined } (this could be done via refine though).

But that's true that my frontend will most of the time send only updated fields. I need to try it, this could also works but I need to see if I can enabled exactOptionalPropertyTypes on my project

I also wish I could ignore this feature for data: ... values and only have it apply to where: ... clauses.

God, this is gna break so much of my app - I have a few generic update functions in my app (validated by zod) and because these update functions are used in a load of places comprising of different inputs in each, I mark each field as optional, so the input type could be string or undefined, (nullable in some cases too). And so if I enable exactOptionalPropertyTypes, it's gna error everywhere that does this pattern. Currently I can just pass the validated output straight into prisma as I know its correct, do I now have to manually assign Prisma.Skip everywhere?

Plus one from us on the proposal by @EvHaus:

I also wish I could ignore this feature for data: ... values and only have it apply to where: ... clauses.

We have a similar use-case to @jharrell where our update-pattern allows the client to either pass a value or pass undefined. Passing undefined leads to no change. As our code base is quite big, it'll be hard to impossible for us to adopt exactOptionalPropertyTypes if it is enforced for all Prisma fields. Having it checking just the where: -clause would be feasible & helpful for us to adopt (and AFAIK also resolve the problem you introduced this feature for, as per docs: https://www.prisma.io/docs/orm/prisma-client/special-fields-and-types/null-and-undefined#using-strict-undefined-checks)

Regarding this issue, one solution would be to first clean your input, then pass it to the prisma functions.

There are libraries for that specific use case.

Disclaimer: Im the author of the package, there are other alternatives too.

Ah, yeah that's a very good point. Thank you for the feedback!

As of right now, yes, I think that typeof optionalEmail is the correct path forward. I'll bring this back to our eng team to see what we can do.

Agreed on exactOptionalPropertyTypes. Unfortunately our team didn't see a reasonable path forward to handle this at build time outside of it.

I appreciate the concept and intent of this change, but enabling exactOptionalPropertyTypes is also causing very large issues in multiple enterprise projects we are maintaining. It seems lots of libraries depend on this being disabled.

Unless typescript wizards come up with another option, what about a typescript-eslint rule? This might be a compromise for existing projects, especially if combined with the ability to disable the actual runtime error.

what about an additional property on the level of where, to define the required parameters, this could enable users to opt in into this feature and exspecialy when using deleteMany or similar this would add an security like layer.

Thanks for the feedback and for bringing the comment over from the original issue 🙏

We understand that this ranges from a "medium" to "extra extra large" change in folks' projects. We want to make that transition as smooth as possible. If you could provide examples of where the current process is painful, that would help us develop something better moving forward.

Full disclosure: we don't exactly know how we're going to do that yet. Right now we're thinking through changes to the API, code mods, and a potential "reverse" Preview feature that could be enabled in Prisma 6. We're thinking through all of the options and will be sure to update folks when we have a better idea of what the eng team wants to do.

I know that's not a super satisfactory answer right now, but it's the one we have at the moment. Thank you again for the feedback and we're looking forward to more 🙂

Here's a (simplified) example of the kind of thing I do commonly that is causing issues with this change enabled

const where =
  name || ids?.length || someOtherEntityId
    ? {
        name: { contains: name, mode: 'insensitive' as const },
        id: { in: ids },
        someOtherEntityId,
      }
    : undefined;
// this.DB() returns a prisma client
const [total, items] = await this.DB().$transaction([
  this.DB().myModel.count({ where }),
  this.DB().myModel.findMany({
    where,
    skip: offset,
    take: limit,
    orderBy: { name: 'asc' },
  }),
]);

This is to implement an endpoint like GET /myModel?name=abc&id=1&id=2&someOtherEntityId=3 where those query params are optional. In reality I have more query params than this but you get the idea.

I was also caught off guard that the types let undefined through but then it fails at runtime (which I realize is because of my tsconfig settings, but noting it since I assume I'm not the only one). That, in my opinion, is a bad experience and goes against most of my experience with prisma. For 99% of my other use of prisma I know if my query typechecks then it is probably right, which is one of the reasons I'm such a big fan of prisma. Losing that experience here would be significant IMO.

This is where you should use null instead of undefined. null is still valid and filters where the value is NULL in the database. undefined is not permitted. If you want undefined to be considered as null in your example you could do:

const vehicle = await this.prismaService.vehicle.findFirst({
      where: { id: vehicleId || null },
 });

This doesn't work when it is an id and the type can't be null

Using satisfies TS keyword instead of type annotation should help here:

const input = {} satisfies Prisma.ItemUncheckedCreateInput;

we are using js deconstructor as a workaround for now:

...hasSkip ? { skip:...} : {},

+1
This is extra annoying since typescript doesn't complain about this:

await prisma.person.update({
  where: {
    id,
  },
  data: {
    // `emails` and `addresses` are both JSON fields
    emails: undefined, // Type 'undefined' is not assignable to type 'Skip | { ifUndefined: {}; } | InputJsonValue | JsonNull | { readonly [x: string]: Exact<InputJsonValue | null | undefined, InputJsonValue | null | undefined>; } | { ...; } | { ...; } | {}
    addresses: [undefined], // No TS error here, but causes a prisma runtime error
  },
});

I wrote a middleware that I think will be sufficient:

  client.$use(async (params, next) => {
    const checkForUndefined = (obj: any) => {
      for (const key in obj) {
        if (obj[key] === undefined) {
          throw new Error(
            `Explicitly \`undefined\` values are not allowed in where clause (key: ${key})`
          );
        }
        if (obj[key]) {
          if (obj[key].constructor === Object) {
            checkForUndefined(obj[key]);
          } else if (Array.isArray(obj[key])) {
            for (const item of obj[key]) {
              checkForUndefined(item);
            }
          }
        }
      }
    };
    const checkWhere = (obj: any) => {
      if (obj?.where && obj.where.constructor === Object) {
        if (Object.keys(obj.where).length === 0) {
          throw new Error('Empty where clause is not allowed');
        }
        checkForUndefined(obj.where);
      }
    };
    checkWhere(params.args);
    const checkIncludes = (obj: any) => {
      if (obj?.include && obj.include.constructor === Object) {
        for (const relation of Object.values(obj.include)) {
          checkWhere(relation);
          checkIncludes(relation);
        }
      }
    };
    checkIncludes(params.args);

    return next(params);
  });

Hi @ace130-github, yes, please open a docs issue and we'll resolve that :)

..come to think of it, this would cause surprise bugs even during development not just upgrades. Compile-time errors are critical for a feature like this.

It's not enabled on v6 unless you enabled on schema, but still not fatal on compile, just on runtime