Skip to content

Depend on packs-specification instead of packs - #113

Open
corsonknowles wants to merge 1 commit into
rubyatscale:mainfrom
corsonknowles:use-packs-specification
Open

corsonknowles wants to merge 1 commit into
rubyatscale:mainfrom
corsonknowles:use-packs-specification

Conversation

@corsonknowles

Copy link
Copy Markdown

Why

The README asks apps to install packs-rails in all environments, so its runtime dependencies go into every app's production bundle. Right now that dependency is the full packs gem: the packs CLI, which brings in packwerk, code_ownership, parse_packwerk, tty-prompt and others.

packs-rails only uses three things from it: Packs.all, Packs.find and Packs::Pack (#name, #relative_path, #is_gem?). All three are defined in packs-specification, which packs already depends on. packs-specification's entry point says this is its purpose:

We let packs-specification define some API methods such as all, find, and for_file, because this allows a production environment to require packs-specification only and get some simple functionality, without needing to load all of packs.

This follows the same approach as rubyatscale/pack_stats#76.

What changed

  • gemspec: runtime dependency packs → packs-specification
  • lib/packs-rails.rb: require 'packs' → require 'packs-specification'. No other file in lib/ requires packs.
  • Version bump 0.1.0 → 0.1.1 so CD publishes on merge. Happy to drop this or make it 0.2.0 if you'd rather release separately.

The specs don't need packs either. spec_helper.rb's require 'packs/rspec/support' also comes from packs-specification. packs is no longer a development dependency.

Verification

Ruby 3.4.11, inside the CI matrix (3.3 / 3.4 / 4.0).

Check Before After
bundle exec rspec (rails-7.0 fixture) 7 examples, 0 failures 7 examples, 0 failures
RAILS_VERSION=8.0 bundle exec rspec 7 examples, 0 failures 7 examples, 0 failures
bundle exec srb tc No errors No errors
bundle exec rubocop 4 offenses 4 offenses (same ones, all in spec/fixtures/rails-8.0, none from this change)
Dev bundle gem count 113 98

Consumer runtime closure. I ran bundle lock on a Gemfile containing only gem 'packs-rails'. It resolves 64 gems with 0.1.0 and 44 with this branch. The 20 that drop are: packs, packwerk, better_html, code_ownership, code_teams, constant_resolver, parse_packwerk, parser, ast, parallel, benchmark, rainbow, smart_properties, pastel, tty-color, tty-cursor, tty-prompt, tty-reader, tty-screen and wisper.

Load smoke test. I ran bundle exec ruby -Ilib -e 'require "packs-rails"' and booted the rails-8.0 fixture app:

  • packs-specification loads. Packs.all returns the fixture's 6 packs, and Packs.find and Packs::Pack are defined.
  • Nothing from the packs gem or packwerk is in $LOADED_FEATURES. defined?(Packs::Cli) and defined?(Packwerk) are both nil.

Compatibility note

If an app called packs CLI APIs (for example Packs.create_pack!) and relied on packs-rails to load that gem, it now needs gem 'packs' in its own Gemfile. Most apps already list it in their development group, because that's where the CLI is used.

🤖 Generated with Claude Code

packs-rails only uses Packs.all, Packs.find and Packs::Pack, all of which
are defined by packs-specification. Depending on the full packs gem pulls
the packs CLI, packwerk and their dependencies into the production bundle
of every app that runs packs-rails (which the README says to install in all
environments).

Bump the version to 0.1.1 so CD publishes the change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@corsonknowles
corsonknowles requested a review from a team as a code owner October 1, 2026 02:03
@github-project-automation github-project-automation Bot moved this to Triage in Modularity Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Triage

Development

Successfully merging this pull request may close these issues.

2 participants