packwerk 3.0.0 → 3.2.2

data/Gemfile.lock

@@ -1,201 +0,0 @@
-PATH
-  remote: .
-  specs:
-    packwerk (3.0.0)
-      activesupport (>= 6.0)
-      ast
-      better_html
-      bundler
-      constant_resolver (>= 0.2.0)
-      parallel
-      parser
-      sorbet-runtime (>= 0.5.9914)
-      zeitwerk (>= 2.6.1)
-
-GEM
-  remote: https://rubygems.org/
-  specs:
-    actionpack (7.0.3.1)
-      actionview (= 7.0.3.1)
-      activesupport (= 7.0.3.1)
-      rack (~> 2.0, >= 2.2.0)
-      rack-test (>= 0.6.3)
-      rails-dom-testing (~> 2.0)
-      rails-html-sanitizer (~> 1.0, >= 1.2.0)
-    actionview (7.0.3.1)
-      activesupport (= 7.0.3.1)
-      builder (~> 3.1)
-      erubi (~> 1.4)
-      rails-dom-testing (~> 2.0)
-      rails-html-sanitizer (~> 1.1, >= 1.2.0)
-    activesupport (7.0.3.1)
-      concurrent-ruby (~> 1.0, >= 1.0.2)
-      i18n (>= 1.6, < 2)
-      minitest (>= 5.1)
-      tzinfo (~> 2.0)
-    ast (2.4.2)
-    better_html (2.0.1)
-      actionview (>= 6.0)
-      activesupport (>= 6.0)
-      ast (~> 2.0)
-      erubi (~> 1.4)
-      parser (>= 2.4)
-      smart_properties
-    builder (3.2.4)
-    byebug (11.1.3)
-    coderay (1.1.3)
-    concurrent-ruby (1.1.10)
-    constant_resolver (0.2.0)
-    crass (1.0.6)
-    diff-lcs (1.5.0)
-    erubi (1.11.0)
-    i18n (1.12.0)
-      concurrent-ruby (~> 1.0)
-    json (2.6.2)
-    language_server-protocol (3.16.0.3)
-    loofah (2.18.0)
-      crass (~> 1.0.2)
-      nokogiri (>= 1.5.9)
-    m (1.6.0)
-      method_source (>= 0.6.7)
-      rake (>= 0.9.2.2)
-    method_source (1.0.0)
-    mini_portile2 (2.8.0)
-    minitest (5.16.2)
-    minitest-focus (1.3.1)
-      minitest (>= 4, < 6)
-    mocha (1.14.0)
-    netrc (0.11.0)
-    nokogiri (1.13.8)
-      mini_portile2 (~> 2.8.0)
-      racc (~> 1.4)
-    parallel (1.22.1)
-    parser (3.1.2.1)
-      ast (~> 2.4.1)
-    prettier_print (0.1.0)
-    pry (0.14.1)
-      coderay (~> 1.1)
-      method_source (~> 1.0)
-    racc (1.6.0)
-    rack (2.2.4)
-    rack-test (2.0.2)
-      rack (>= 1.3)
-    rails-dom-testing (2.0.3)
-      activesupport (>= 4.2.0)
-      nokogiri (>= 1.6)
-    rails-html-sanitizer (1.4.3)
-      loofah (~> 2.3)
-    railties (7.0.3.1)
-      actionpack (= 7.0.3.1)
-      activesupport (= 7.0.3.1)
-      method_source
-      rake (>= 12.2)
-      thor (~> 1.0)
-      zeitwerk (~> 2.5)
-    rainbow (3.1.1)
-    rake (13.0.6)
-    rbi (0.0.15)
-      ast
-      parser (>= 2.6.4.0)
-      sorbet-runtime (>= 0.5.9204)
-      unparser
-    regexp_parser (2.5.0)
-    rexml (3.2.5)
-    rubocop (1.34.1)
-      json (~> 2.3)
-      parallel (~> 1.10)
-      parser (>= 3.1.2.1)
-      rainbow (>= 2.2.2, < 4.0)
-      regexp_parser (>= 1.8, < 3.0)
-      rexml (>= 3.2.5, < 4.0)
-      rubocop-ast (>= 1.20.0, < 2.0)
-      ruby-progressbar (~> 1.7)
-      unicode-display_width (>= 1.4.0, < 3.0)
-    rubocop-ast (1.21.0)
-      parser (>= 3.1.1.0)
-    rubocop-performance (1.14.3)
-      rubocop (>= 1.7.0, < 2.0)
-      rubocop-ast (>= 0.4.0)
-    rubocop-shopify (2.9.0)
-      rubocop (~> 1.33)
-    rubocop-sorbet (0.6.11)
-      rubocop (>= 0.90.0)
-    ruby-lsp (0.2.3)
-      language_server-protocol
-      sorbet-runtime
-      syntax_tree (>= 2.4)
-    ruby-progressbar (1.11.0)
-    smart_properties (1.17.0)
-    sorbet (0.5.10313)
-      sorbet-static (= 0.5.10313)
-    sorbet-runtime (0.5.10313)
-    sorbet-static (0.5.10313-universal-darwin-14)
-    sorbet-static (0.5.10313-universal-darwin-15)
-    sorbet-static (0.5.10313-universal-darwin-16)
-    sorbet-static (0.5.10313-universal-darwin-17)
-    sorbet-static (0.5.10313-universal-darwin-18)
-    sorbet-static (0.5.10313-universal-darwin-19)
-    sorbet-static (0.5.10313-universal-darwin-20)
-    sorbet-static (0.5.10313-universal-darwin-21)
-    sorbet-static (0.5.10313-universal-darwin-22)
-    sorbet-static (0.5.10313-x86_64-linux)
-    sorbet-static-and-runtime (0.5.10313)
-      sorbet (= 0.5.10313)
-      sorbet-runtime (= 0.5.10313)
-    spoom (1.1.11)
-      sorbet (>= 0.5.9204)
-      sorbet-runtime (>= 0.5.9204)
-      thor (>= 0.19.2)
-    spring (4.0.0)
-    syntax_tree (3.3.0)
-      prettier_print
-    tapioca (0.9.2)
-      bundler (>= 1.17.3)
-      netrc (>= 0.11.0)
-      parallel (>= 1.21.0)
-      pry (>= 0.12.2)
-      rbi (~> 0.0.0, >= 0.0.14)
-      sorbet-static-and-runtime (>= 0.5.9204)
-      spoom (~> 1.1.0, >= 1.1.11)
-      thor (>= 1.2.0)
-      yard-sorbet
-    thor (1.2.1)
-    tzinfo (2.0.5)
-      concurrent-ruby (~> 1.0)
-    unicode-display_width (2.2.0)
-    unparser (0.6.5)
-      diff-lcs (~> 1.3)
-      parser (>= 3.1.0)
-    webrick (1.7.0)
-    yard (0.9.28)
-      webrick (~> 1.7.0)
-    yard-sorbet (0.6.1)
-      sorbet-runtime (>= 0.5)
-      yard (>= 0.9)
-    zeitwerk (2.6.4)
-
-PLATFORMS
-  ruby
-  x86_64-darwin
-  x86_64-darwin-20
-
-DEPENDENCIES
-  byebug
-  constant_resolver
-  m
-  minitest-focus
-  mocha
-  packwerk!
-  railties
-  rake
-  rubocop-performance
-  rubocop-shopify
-  rubocop-sorbet
-  ruby-lsp (~> 0.2.1)
-  sorbet-static-and-runtime
-  spring
-  tapioca
-  zeitwerk
-
-BUNDLED WITH
-   2.4.7

data/RESOLVING_VIOLATIONS.md

@@ -1,81 +0,0 @@
-# Resolving Violations
-
-Violations can be [recorded as a deprecation](#recording-violations) or (better!) [eliminated](#eliminating-violations).
-
-## Recording Violations
-💡 New privacy and dependency violations are never hard-blocked. There are many very valid reasons to run `bin/packwerk update-todo`, adding new violations to `package_todo.yml` files. Even if you feel your reason might not be "valid," if your judgement says adding the violation and shipping your change will produce positive impact, trust your gut.
-
-### Emergency Fixes
-❔ Is it a revert or is there a lot of urgency because you are fixing a production bug impacting customers?
-
-➡️ Simply run `bin/packwerk update-todo`, and address the violation when the customer issue is resolved.
-
-### Improving System Design
-❔ Are you improving system boundaries by renaming or moving a file, class, constant,` or module?
-
-➡️ Simply run `bin/packwerk update-todo`. We've improved how our system is organized, so the new violations are natural.
-
-### Making Things Explicit
-❔ Are you making something that was implicit (hidden to Packwerk) explicit, such as adding a Sorbet signature, using a class instead of a method call, or something similar?
-
-➡️ Simply run `bin/packwerk update-todo`. Making something implicit explicit and capturing that as a new violation is a strict improvement.
-
-### Temporary State
-❔ Is the violation temporary because you will soon delete the code or is it part of a refactor to improve system boundaries and reduce violations overall?
-
-➡️ Simply run `bin/packwerk update-todo`. Sometimes things get "worse" before they get better.
-
-### Delivering Features
-❔ Are you in a rush to get a feature out and product, your manager, or an internal sense of urgency has made you feel like you can't resolve system design issues?
-
-➡️ Stay strong. Eliminate the violation. It is important to build a sustainable business that optimizes for the long-term. Look for advocates such as from mentors or within your team who can help you justify improving system design.
-
-## Eliminating Violations
-💡 Dependency and privacy violations are Packwerk's signal that what we've stated about the desired system design (what
-packages exist and what lives in them, the dependencies in a package.yml, and the public interface in the package's public folder) doesn't match the reality of our system.
-If what we've stated about our system design doesn't feel right, then the violations won't make sense either! Make sure to think through system design before addressing a violation.
-
-### Moving Things Around
-❔ Does the code you're writing (or changing) live in the right package? Does the code you're referencing live in the right package?
-
-If not, find a better place for it to live.
-
-Otherwise, follow the guide for eliminating [Privacy Violations](#privacy-violations) or [Dependency Violations](#dependency-violations).
-
-### Privacy Violations
-💡  Packwerk thinks something is a privacy violation if you're referencing a constant, class, or module defined in the private implementation (i.e. not the public folder) of another package. We care about these because we want to make sure we only use parts of a package that have been exposed as public API.
-
-An explicit and implementation-hiding public API is a cornerstone of well-modularized code.
-
-#### Use Existing Public Interface
-❔ Does the package you're using expose public API in its public folder that supports your use case?
-
-➡️ Use that public API instead!
-
-#### Change The Public Interface
-❔ Can we work with the package's owner to create and use a public API? Or should the thing we're using already be public?
-
-➡️  Work together on a new public API and use that instead! If the thing we're using should be public, move it to the public folder to make it public!
-
-⛈️ If working with the package's owner to improve the API is not possible, run `bin/packwerk update-todo`. Add some context to your PR about why it's not possible.
-
-### Dependency Violations
-💡  Packwerk thinks something is a dependency violation if you're referencing a constant, class, module defined ANYWHERE but your package doesn't list it as an explicit dependency in its `package.yml`. We care about these because it allows us to be systematically intentional about what our code needs to run and helps us untangle and remove dependency cycles from our system.
-
-Thoughtful dependency management is another cornerstone of well-modularized code.
-
-#### Adding Explicit Dependencies
-❔ Do we actually want to depend on the other package? Work with your team to help answer this question!
-
-➡️  Add the other package to your package's `package.yml` `dependencies` key.
-
-⁉️ Did you get a cyclic dependency when CI ran `bin/packwerk validate`?
-
-➡️  Work with your team to think through what link in the cycle we don't want. Remove that link and rerun `bin/packwerk validate`.
-
-#### Changing The System Design
-❔ Can we spend some time to think through changes to the system design that don't require the dependency?
-
-➡️  Work with the owners of the relevant packages, as well as your team, to think through a design that doesn't include the unwanted dependency.
-
-⛈️ If this is not possible within the scope of your changes (think hard about this one!), run `bin/packwerk update-todo`. Add some context to your PR about why it's not possible, and any additional context you may have, such as a possible solution.

data/Rakefile

@@ -1,13 +0,0 @@
-# frozen_string_literal: true
-
-require "bundler/gem_tasks"
-require "rake/testtask"
-
-Rake::TestTask.new(:test) do |t|
-  t.libs << "test"
-  t.libs << "lib"
-  t.test_files = FileList["test/**/*_test.rb"]
-  t.warning = false
-end
-
-task(default: :test)

data/TROUBLESHOOT.md

@@ -1,45 +0,0 @@
-# Troubleshoot
-
-* [Troubleshooting violations](#Troubleshooting-violations)
-  * [Feedback loop](#Feedback-loop)
-  * [Package Dependency violation](#Package-Dependency-violation)
-    * [Interpreting Dependency violation](#Interpreting-Dependency-violation)
-
-## Troubleshooting violations
-
-### Feedback loop
-Packwerk can give feedback via continuous integration (CI) if you have it set up, but that is a long feedback cycle. If you want faster feedback, use Packwerk on the command line locally.
-
-You can specify folders or packages in Packwerk commands for a shorter run time:
-
-     bin/packwerk check components/your_package
-
-     bin/packwerk update-todo components/your_package
-
-_Note: You cannot specify folders or packages for `bin/packwerk validate` because the command runs for the entire application._
-
-![](static/packwerk_check_violation.gif)
-
-### Package Dependency violation
-A constant defined in a package A is referenced from a package B that doesn’t define a dependency on A. Packages define their dependencies in their `package.yml`.
-
-See: [USAGE.md - Enforcing dependency boundary](USAGE.md#Enforcing-dependency-boundary)
-
-#### Interpreting Dependency violation
-
-> /Users/JaneDoe/src/github.com/sample-project/billing/app/jobs/document_processing_job.rb:48:6
-> Dependency violation: ::Edi::Source belongs to 'edi', but 'billing' does not specify a dependency on 'edi'.
-> Are we missing an abstraction?
-> Is the code making the reference, and the referenced constant, in the right packages?
->
-> Inference details: 'Edi::Source' refers to ::Edi::Source which seems to be defined in edi/app/models/edi/source.rb.
-
-There has been a dependency violation in the package `billing` to the package `edi`, through the use of the constant `Edi::Source` in the file `billing/app/jobs/document_processing_job.rb`.
-
-##### Suggestions
-If a package declares dependencies, assume that some thought went into that. It is unlikely that the correct fix is to add another dependency.
-Check if the code containing the reference and the code defining the constants are in the right packages. If not, fix that by moving code around.
-
-If a dependency A -> B is not desired, but a dependency B -> A is OK, consider using [dependency inversion](https://www.sandimetz.com/blog/2009/03/21/solid-design-principles).
-
-If you’re getting stuck, find people with context about the two packages involved and ask for their opinion.

data/UPGRADING.md

@@ -1,54 +0,0 @@
-# Upgrading from 1.x to 2.0
-
-With Packwerk 2.0, we made a few changes to simplify the setup. Updating will require removing some previously necessary files and configuration.
-
-## Gem group
-
-Because packwerk is no longer involved in specifying the application's inflections, it doesn't have to live in the `production` group in your `Gemfile` anymore. We recommend moving it to the `development` group.
-
-## Removing application config caches
-
-### Load paths
-We no longer require the `load_paths` key in `packwerk.yml`. You can simply delete the load_paths key as it will not be read anymore. Instead, Packwerk will ask Rails for load paths. If you're using spring, make sure to properly set up spring (see [USAGE.md](USAGE.md#setting-up-spring)) to keep packwerk fast.
-
-### Inflections
-We no longer require a custom `inflections.yml` file. Instead, you'll want to revert BACK to using the `inflections.rb` initializer as you would have done prior to adopting packwerk. To do this, you'll want to convert back to using the plain [ActiveSupport Inflections API](https://api.rubyonrails.org/classes/ActiveSupport/Inflector/Inflections.html).
-
-
-Given the following example `inflections.yml`, here is an example `inflections.rb` that would follow. Tip: if you're using git, you can run `git log config/inflections.yml`, find the first commit that introduced `inflections.yml`, find the COMMIT_SHA, and then run `git show COMMIT_SHA` to see what your inflections file looked like before (note that you may have changed `inflections.yml` since then, though).
-
-`config/inflections.yml`
-```yml
-# List your inflections in this file instead of `inflections.rb`
-# See steps to set up custom inflections:
-# https://github.com/Shopify/packwerk/blob/main/USAGE.md#Inflections
-
-acronym:
- - 'HTML'
- - 'API'
-
-singular:
- - ['oxen', 'oxen']
-
-irregular:
- - ['person', 'people']
-
-uncountable:
- - 'fish'
- - 'sheep'
-```
-
-`config/initializers/inflections.rb`
-```ruby
-ActiveSupport::Inflector.inflections(:en) do |inflect|
-  inflect.acronym('HTML')
-  inflect.acronym('API')
-
-  inflect.singular('oxen', 'oxen')
-
-  inflect.irregular('person', 'people')
-
-  inflect.uncountable('fish')
-  inflect.uncountable('sheep')
- end
-```