Naming convention?

[kristiandupont]

Looking at the README, there is a mix of PascalCasing and camelCasing for the examples of Zod schemas. I can't tell if it's on purpose and there is a pattern or if it's just because it's not considered important.

It seems to me that camelCasing is the more correct approach as it's a pretty widely accepted convention in TS to use PascalCasing for types and camelCasing for all instances and things that survive into JS, except classes which overlap the two.

I am asking because I am working on introducing Zod generation into Kanel. I would like to get it right as it's already a pretty busy field to maneuver with snake_casing being the default in Postgres.

[JacobWeisenburger]

It seems to me that camelCasing is the more correct approach as it's a pretty widely accepted convention in TS to use PascalCasing for types and camelCasing for all instances and things that survive into JS, except classes which overlap the two.

You are correct. Generally this is the convention. However, some parts of the README were written a long time ago and/or by many different people, so it has been pretty loose. We are currently in process of updating the docs. So things like this should be dealt with eventually. You are more than welcome to submit a PR for any casing issues that you see. That way we can prioritize those issues.

Thanks for the observation.

[phpjob]

Hey @JacobWeisenburger, would you also recommend to write object names also camelCase
https://zod.dev/?id=objects

// all properties are required by default
const Dog = z.object({
  name: z.string(),
  age: z.number(),
});

Instead use better:

// all properties are required by default
const dog = z.object({
  name: z.string(),
  age: z.number(),
});

If this would be the case, i would work on a PR to keep it more consistent.

[kristiandupont]

@JacobWeisenburger ..two years later, and I did :-D
#3285

[scotttrinh]

Yeah, some people like using PascalCase for the schema rather than camelCaseSchema to take advantage of TypeScript being able to have a type and a value share the same name. FooBar.parse -> FooBar rather than fooBarSchema.parse -> FooBar. Definitely a stylistic thing that I don't think it makes sense for us to be too prescriptive about, but having a consistent style in the documentation is definitely a good thing.

[StefanTerdell]

I'm partial to $Thing for the schema and Thing for the type, myself. $Thing is technically still camelCase due to the prefix $ being uncased, but the name itself is identical to the type. It's also easier to tell the schema and type references apart visually.

const $Person = z.object({ ... });

type Person = z.infer<typeof $Person>

[thebiltheory]

I like the $Person, it makes sense when you define a schema with "$schema": ""

[phpjob]

We have an active discussion about the developers favorite topic naming conventions 😄.

And one argument is zod. That it writes its object schemas in the documentation as Pascal notation -> https://zod.dev/?id=objects

I understand the point that it makes little sense to be restrictive. And I would agree with that.

As a recipient of the documentation, the question came up. What does zod recommend? What is their stance?

Because one could conclude since they write other places as camel case, the recommendation may be to write Pascal in the specific cases.

However, the conclusion could be wrong. The way I read it here.

Is it possible to record zod's position on naming conventions in the documentation?

I can well imagine that this could help one or the other discussion 😃 .

[kristiandupont]

For what it's worth, I implemented Zod schema generation in Kanel, where types are camel cased per default. This feels like the correct approach to me.

[kristiandupont]

Colin rejected this, so I will close the discussion.

[louispotok]

In case anyone is still looking at this, I'm curious why the zod issue types use snake_case? I think that's the only place in zod where it's used.

[dy0gu]

In case anyone is still looking at this, I'm curious why the zod issue types use snake_case? I think that's the only place in zod where it's used.

I was wondering the same thing, seems weird to still have snake_case only in those specific fields. The only reason I even noticed it is because they were triggering the naming convention rule on my linter...

[rockResolve]

Beware that using the same case for the schema and the type might cause your IDE (at least webstorm) problems. When looking up a Dog reference, it lists both the schema and type reference, and asks which you want.