Migrate frontpage post to be lexicon first #199
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
tom-sherman
commented
Nov 6, 2024
tom-sherman
force-pushed
the
lexicon-first-post
branch
from
c4853a9 to
585075e
Compare
github-actions
bot
added
the
documentation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the first PR in a series to migrate us to be "lexicon-first". In that we define our types in atproto lexicon DSL and then generate the types, schemas, and API clients from that. We've had the lexicons defined for a while although this PR updates lex-cli and regenerates the client code, meaning you can ignore the diff on the files in
packages/frontpage-atproto-client/src/.This PR also changes the frontpage-atproto-client package to be built, this matches how lex-cli is used within the atproto repo and gets around some weirdness in it's codegen output with regards to some imports including
.jsfile extensions - Next.js compiler can't handle these so we let TypeScript build the packages.Important
This changes the local dev workflow slightly, I've updated the readme to reflect. Basically just run
turbo run devinstead ofpnpm run devfor frontpage.I'm going type-by-type with the end goal of basically removing all of our frontpage-specific code in the
lib/data/atprotofolder.This work is a kind of a pre-requisite for implementing #232 as it makes the refactor way safer.