Don't validate known lexicons at runtime

[gaearon]

Here's what I'm seeing in the app's module initialization sequence with CPU throttling on:

It looks like we're spending client's CPU cycles validating that our own schemas are valid. I'm not sure it makes sense for a client to do that in production. From what I understand, these schemas are known at the build time, there's no way for them to have changed by any other way than deploying our code. So if they were valid when the app was built, it seems unnecessary to check whether they're valid on every end user's computer.

Without these lines, the init time shrinks considerably:

[pfrazee]

I'm 100% on board with this

[dholms]

I very much support something to this effect 👍

I'm actually curious if it makes sense to remove the check all together? I think this made it in when we thought lexicons might be getting loaded into the client much more dynamically. But the way things stand, you know all lexicons at build time. It may make sense down the line to allow dynamically adding a lexicon which would require a parsing check

We actually run these same typechecks on the lexicon documents during codegen, before they even have the chance to get build into the client. So it's not really serving us in DEV either

[devinivy]

What if the add() method here received a LexiconDoc rather than an unknown? Our built schemas are typed, so we should be ready to roll. We should just ensure lexicon doc parsing is exposed so that external docs can be validated and used as well.

atproto/packages/api/src/client/lexicons.ts

Line 7558 in 8637c36

export const schemas: LexiconDoc[] = Object.values(schemaDict) as LexiconDoc[]

[gaearon]

Pushed changes:

• Lexicons#constructor and Lexicons#add deal with LexiconDoc now.
  • Had to tweak a few types in tests for that.
• Added top-level parseLexiconDoc(unknown): LexiconDoc as a throwing refinement.
  • Technically this could be done via explicit Zod lexiconDoc.parse() and a cast so we don't have to add it. I like that having this export suggests it's the supported way to validate those at runtime though so I think it's worth keeping.
  • Changed a few callsites that used Zod lexiconDoc.parse() to the new parseLexiconDoc() refinement.
  • This means we don't have to export Zod lexiconDoc anymore. I kept it around for consistency with how we export other Zod schemas.
• I got rid of the special LexiconDocMalformedError error. It seems like it existed to highlight which specific schema failed but this isn't useful now that you do the validation yourself. Having direct access to Zod error without wrappers seems nicer — e.g. it lets us do error.format() which LexiconDocMalformedError didn't let us do. It doesn't seem like this library tries to abstract away Zod so let's just expose its raw error directly.

Hope this works!

[gaearon]

Technically removing this would necessitate going to 0.3.0 on the off-chance that someone imports it. Not sure if we care about this at this point. Happy to re-add.

[dholms]

biiigg yup 👍

thanks for pushing on this!

[Olegbobokhidze]

❤️