bundler-ignore-dependency
CLAUDE.md7 starsChanged 10 months agoMITView on GitHub
This document provides guidance for LLMs and developers working on this project. bundler-ignore-dependency is a Bundler plugin that allows developers to ignore version constraints on Ruby, RubyGems, or gem dependencies. This is useful in monorepo scenarios where you want to test gems against specific versions without strict version constraints. The GitHub Actions workflow (.github/workflows/ci.yml) automatically: - Fetches the latest 2 major Bundler versions dynamically - Tests against Ruby 3.3, 3.4, and 4.0 - Runs RuboCop linting - Runs all 86…
The file
Show its rules and text
We split this CLAUDE.md into the rules it gives an agent
16 rules. About 0 are common, 9 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 68
Always run the full test suite: - Use bin/minitest to ensure nothing breaks
- Very specific: line 69
Check code style: - Run bin/rubocop -a to auto-correct style issues
- Distinctive: line 70
Update documentation: - If changing behavior, update relevant docs
- Very specific: line 77
Use write_gemfile() to set up test Gemfiles
- Very specific: line 78
Use run_bundle_install() to install the plugin before testing
- Very specific: line 79
Always create test gems with create_test_gem() and create_git_gem() helpers
- Very specific: line 155
If you see "Undefined local variable or method ignore_dependency!", ensure:
- Distinctive: line 161
Run tests locally with that Bundler version
- Distinctive: line 162
Check the GitHub Actions logs for the exact failure
- Distinctive: line 163
Ensure patches handle version-specific behavior
- Very specific: line 166
Run bin/rubocop -a to auto-correct most style issues.
- Distinctive: line 167
Check the Shopify Ruby Style Guide
- Distinctive: line 169
Consider if an exception is needed (rare, requires RuboCop comment)
- Distinctive: line 180
If working on this project and encountering issues:
- Distinctive: line 181
Check the test files for examples
- Distinctive: line 184
Look at recent commits for context on recent changes
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Working with bundler-ignore-dependency
This document provides guidance for LLMs and developers working on this project.
Project Overview
bundler-ignore-dependency is a Bundler plugin that allows developers to ignore version constraints on Ruby, RubyGems, or gem dependencies. This is useful in monorepo scenarios where you want to test gems against specific versions without strict version constraints.
Development Workflow
Running Tests
# Run all tests
bin/minitest
# Run unit tests only
bin/minitest test/unit
# Run CLI tests only
bin/minitest test/cli
# Run a specific test file
bin/minitest test/cli/ignore_dependency_test.rbCode Linting
# Check code style
bin/rubocop
# Auto-correct style violations
bin/rubocop -aCI/CD
The GitHub Actions workflow (.github/workflows/ci.yml) automatically:
- Fetches the latest 2 major Bundler versions dynamically
- Tests against Ruby 3.3, 3.4, and 4.0
- Runs RuboCop linting
- Runs all 86 tests
Key Architecture
Patch System
The plugin works by monkey-patching Bundler classes to intercept dependency resolution:
- DefinitionPatch - Stores ignored dependencies list
- DSLPatch - Provides
ignore_dependency!DSL method - ResolverPatch - Filters out ignored dependencies during resolution
- MatchMetadataPatch - Handles version requirement manipulation
- LazySpecificationPatch - Prevents ignored gems from being locked
- SharedHelpersPatch - Validates DSL arguments
- MaterializationPatch - Prevents fetching of ignored gems
Test Structure
test/unit/- Unit tests for each patch class and the main moduletest/cli/- Integration tests that test the full workflow with Bundler
Important Notes for LLMs
When Making Changes
- Always run the full test suite - Use
bin/minitestto ensure nothing breaks - Check code style - Run
bin/rubocop -ato auto-correct style issues - Update documentation - If changing behavior, update relevant docs
- Follow Shopify Ruby Style Guide - The project enforces this via RuboCop
Test Patterns
- Unit tests inherit from
BundlerTestintest/unit/test_helper.rb - CLI tests inherit from
CliTestintest/cli/test_helper.rb - Use
write_gemfile()to set up test Gemfiles - Use
run_bundle_install()to install the plugin before testing - Always create test gems with
create_test_gem()andcreate_git_gem()helpers
Plugin Installation in Tests
The plugin must be installed before it can be used in a Gemfile:
run_bundle_install(dir) # This installs the plugin first, then runs bundle installNOT:
run_bundle(dir, "install") # This skips plugin installation and will failDependencies
Runtime
- bundler - The gem dependency manager (Bundler 2.7+, 4.0+)
- ruby - Ruby 3.1 or later
Development
- minitest - Testing framework
- rubocop - Code linter
- rubocop-shopify - Shopify's RuboCop configuration
- rubocop-minitest - Minitest-specific RuboCop rules
Useful Commands
# Bundle setup
bundle install
# Run tests
bin/minitest
# Lint code
bin/rubocop
# Auto-fix linting issues
bin/rubocop -a
# View gem information
bundle info bundler-ignore-dependency
# Run specific test
bin/minitest -n test_name
# Run tests matching a pattern
bin/minitest -n /pattern/File Structure
├── lib/bundler/ignore_dependency/
│ ├── version.rb # Version constant
│ ├── definition_patch.rb # Stores ignored dependencies
│ ├── dsl_patch.rb # Provides ignore_dependency! DSL
│ ├── resolver_patch.rb # Filters dependencies
│ ├── match_metadata_patch.rb # Handles version matching
│ ├── lazy_specification_patch.rb # Prevents lockfile inclusion
│ ├── shared_helpers_patch.rb # Validates DSL
│ └── materialization_patch.rb # Prevents gem fetching
├── test/
│ ├── unit/ # Unit tests for patches
│ └── cli/ # Integration tests
├── .github/workflows/
│ └── ci.yml # GitHub Actions CI configuration
├── Gemfile # Development dependencies
└── bundler-ignore-dependency.gemspec # Gem specificationCommon Issues
Plugin Not Loading in Tests
If you see "Undefined local variable or method ignore_dependency!", ensure:
- Using
run_bundle_install(dir)notrun_bundle(dir, "install") - The plugin path is correctly passed to
bundle plugin install
Test Failures with Different Bundler Versions
The CI matrix tests against multiple Bundler versions. If a test fails with specific versions:
- Run tests locally with that Bundler version
- Check the GitHub Actions logs for the exact failure
- Ensure patches handle version-specific behavior
Linting Issues
Run bin/rubocop -a to auto-correct most style issues. For issues that can't be auto-corrected:
- Check the Shopify Ruby Style Guide
- Review the specific RuboCop rule documentation
- Consider if an exception is needed (rare, requires RuboCop comment)
References
Questions or Issues?
If working on this project and encountering issues:
- Check the test files for examples
- Review the patch classes to understand the implementation
- Consult this guide for common patterns and issues
- Look at recent commits for context on recent changes
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

