jsr: no slow types requirement makes zod exports unusable

[bjesuiter]

Hi there!

I really like jsr, but I suggest making the --no-slow-types requirement officially simply a default publishing option, which package authors may opt out of.

The Zod Problem

I'm using the zod package a lot for runtime type validation and simultaneously having the type correctly inferred in ts, which mitigates the risk of mismatches between runtime validation and the ts type system.
Having to specify the complex type of a ZodSchema by hand, is pure pain.
Also, specifying the resulting inferred type for the variable again makes z.infer completely useless.

My Proposal: Show n info or a warning in jsr when package uses slow types

I understand that it's better for jsr to have the types. But I would like you to give the option to the package author and simply show a note like "Careful: uses slow types!" on the package page.
Opting out of zap is ok for now, but it feels like a dirty thing to do and I would like that it's clarified, that sometimes it may be ok to opt out of the --no-slow-types requirement.

Sidenote: Please do not block publishing of those packages in the future

Per default, --no-slow-types can be true, but when a package opts out of this requirement, it should not be blocked from being published to jsr.
Otherwise, we 'll create one new registry for some packages (JSR) and not other packages. When they do not match the --no-slow-types requirement, they might be published to another registry or avoid jsr completely avoided because of that.

[bjesuiter]

Update:

I found out that deno 1.42 has a new flag: --allow-slow-types, which seems to do what I wanted.
I'll check it out!

[NfNitLoop]

mitigates the risk of mismatches between runtime validation and the ts type system.

I ran into a similar issue over in #23396.

My preference would also be to be able to use zod inferred types somehow. But, if you DO want to hand-roll your own "fast" type(s), here's a handy pattern for making sure they don't diverge:

import { z } from "npm:zod@3.22.4"

export type Foo = {
    foo: string,
}

// Don't use this type in your code, it's only for testing.
export type zFoo = z.infer<typeof zFoo>
// Do use this value in your code, to deserialize a `Foo`. But don't export it from JSR.
export const zFoo = z.object({
    foo: z.string().min(1),
    bar: z.number(), // Demonstrates the error.
})

// In the same file as above if you're feeling lazy, or in a separate _test.ts file:

// This makes sure that Foo and zFoo are mutually-assignable.
// You'll get type errors here if you forgot to update one or the other.
function _zFoo1(x: Foo): zFoo { return x }
function _zFoo2(x: zFoo): Foo { return x }