-
Notifications
You must be signed in to change notification settings - Fork 350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize types/definitions build process #3692
Conversation
Improve the build system to only rebuild types when source files change, rather than rebuilding for every build. This is accomplished by: 1. Adding explicit file dependencies to the types target 2. Creating a new build_types_when_needed target that tracks source files 3. Adding a convenient alias in the root BUILD.bazel
srcs = [ | ||
"scripts/config.capnp", | ||
":types_worker", | ||
"//:node_modules/prettier", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is interesting... I think it is saying that if we bump the version of prettier it might change the types that need generating?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but I think it should re-trigger since types generator calls prettier() javascript API directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suck it and see?
It actually doesn't build. I guess Claude didn't test the code before pushing... |
I'm a bit bearish on LLMs in general, but based on how hard figuring out the nuances of Bazel is, we can't expect language models to do well here and not hallucinate things that are not what they seem to be at all:
|
So after some digging I found out that our types generation depends on jsg server. Which means whenever we change any file in this repository, type generation is rebuilt. |
Can you explain what you mean with "jsg server" and "any file in this repository"? Based on the direct dependencies of |
I mistyped. You're right @fhanau. |
I was too until like two weeks ago. Claude Code is insane. See #3669 and #3673 for examples with transcripts. But it's obviously not perfect. Seems like it didn't do a good job here. I've been thinking about this a bit and I think we need a rule: No "vibe coding", that is, no submitting LLM-generated code where you don't really understand how or why it works. Draft PRs are OK if you want help figuring it out, but the PR must remain in draft until you understand it. (Also please make sure you are following all company policies regarding both LLM use and also whether the particular software is approved for install on company machines. I made my two PRs on a personal machine out of caution. Of course, you can't put company code on personal machines unless it's open source.) |
An attempt to try Claude after getting some confidence from @kentonv. Let's see if this change is worth 0.9$.
Improve the build system to only rebuild types when source files change, rather than rebuilding for every build. This is accomplished by: