Conversation
Every Yardoc method worked out the gem yardoc directory itself by calling PinCache.yardoc_path on a gemspec, so the module could only ever read and write the one location PinCache picks. Callers now compute that path and pass it in, which lets any caller point Yardoc at a directory of its own and lets the spec build into a tmpdir instead of the real user cache. cache becomes build_docs and no longer returns the path; cached? becomes docs_built?; processing? and load! take the path instead of a gemspec. build_pins takes over the load-and-map step from GemPins.build_yard_pins, which now computes the path once and calls the path-taking methods. Extracted from the parked PinCache rewrite so it can land without the module-to-instance conversion that branch also carries.
apiology
added a commit
that referenced
this pull request
Sep 9, 2026
Brings in #102: let callers choose where a gem yardoc is built, by passing the path into every Yardoc method rather than deriving it from the gemspec inside. No conflicts. The two call sites it rewrites sit clear of the regions the earlier four merges touched: GemPins.build_yard_pins is untouched by any of them, and its edit to Library#cache_next_gemspec lands about twenty lines above the retry guard pincache-instance added to the same method. Checked the new API took everywhere rather than only where git merged it. Every Yardoc call site now passes a path -- build_docs and docs_built? and build_pins in gem_pins.rb, processing? in library.rb, load! in the mapper spec -- and none of the old gemspec-taking names survive anywhere in lib or spec. PinCache.yardoc_path, which supplies that path, is still a class method: pincache-instance moved combined and RBS collection entries onto the instance and left the yardoc path where it was. Full suite: 1685 examples, 0 failures, 68 pending.
A YARD plugin decides what a gem documentation contains, and the caller now says which ones it wants. The cache did not: yardoc_path named one plugin and its version as a literal, while yard_gem_path and combined_path named none, so the three entries a gem needs were shared by every declared set. Build docs once and Yardoc.build_docs returns early for the next caller, which then reads pins built under someone else plugins with no way to ask for its own. That is the first of the five failures #103 lists: gem types go stale after a YARD plugin upgrade until you clear the cache by hand. Each of the three keys now carries the plugin set, so a workspace is served what its own conventions declared. Both spellings a caller may use reach the same key, activesupport-concern and the yard-activesupport-concern its gem carries, because the command line passes one and Convention::ActiveSupportConcern the other; a key built verbatim would give them separate caches for identical documentation. The plugin version rides along, so an upgrade invalidates. uncache clears every set for a gem, which is what asking for a gem by name means. The spec asks a workspace for a method the activesupport-concern plugin lifts out of a class_methods block. Declared, the workspace resolves it; dropped, it must not, and on this branch before the change it did. The fixture gem exists to carry that method: nothing in the bundle is written in the ActiveSupport::Concern style, and the plugin changes nothing without it. Verified in both directions. With lib reverted the example reports [1, 1] against an expected [1, 0]. spec/pin/method_spec.rb:552 fails on this branch either way, an Integer#+ signature count that predates this change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E8ckZEYYMDXe9eDNnyxaim
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.
This PR was written by Claude Code on behalf of @apiology.
Problem:
Solargraph::Yardoccan only ever read and write one directory per gem, the onePinCachepicks, because every method works the path out from a gemspec instead of being told it. A caller that wants a gem yardoc somewhere else, including the spec suite, has no way to ask for one.That is why
spec/yardoc_spec.rbcovered a single method: exercising the rest meant writing into the real user cache.Solution: Each
Yardocmethod now takes the gem yardoc path as its first argument, andGemPinsandLibrarycompute it withPinCache.yardoc_path(gemspec)at the call site.cachebecomesbuild_docs,cached?becomesdocs_built?, and a newbuild_pinstakes over the load-and-map step fromGemPins.build_yard_pins. The spec builds into a tmpdir and now coversbuild_docs,processing?andload!.