perf: lazy third-party typedefs#372
Merged
Merged
Conversation
Merged
Contributor
|
Released in |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Adds lazy generation of typedefs for third-party Go deps.
lis add,lis check,lis runandlis buildnow populate a project's typedef cache only for the pkgs that user code imports, rather than every public package of every reachable Go module. Until now, any CLI command that touched the cache (re)generated it eagerly, e.g.lis add github.com/golang-migrate/migrate/v4walked the full dep tree and generated typedefs for all driver and SDK pkgs even if unimported.In the new lazy setup:
lisette.tomlis the allowlist. The manifest declares every Go module any future import can reach.target/.lisette/typedefs/is the working set, grows lazily as users write imports.lis syncwarms the cache from source for offline or CI use, exits non-zero when bindgen fails.Blank imports follow Go's semantics:
import _ "go:github.com/foo/bar"validates that the module is declared but never reads or generates the typedef, so side-effect-only deps stay link-only.A project-scoped lock at
target/.lisette/.lis-target.lockserializes concurrentlis check/run/build/syncand LSP analysis so they do not race ontarget/go.modwhile bindgen is running. The LSP shares the bindgen runner with the CLI, so opening a file on a fresh checkout fills the cache as the editor discovers imports.