|
| 1 | +# Checkers |
| 2 | +## Privacy Checker |
| 3 | +The privacy checker extension was originally extracted from [packwerk](https://github.com/Shopify/packwerk). |
| 4 | + |
| 5 | +A package's privacy boundary is violated when there is a reference to the package's private constants from a source outside the package. |
| 6 | + |
| 7 | +To enforce privacy for your package, set `enforce_privacy` to `true` or `strict` on your pack: |
| 8 | + |
| 9 | +```yaml |
| 10 | +# components/merchandising/package.yml |
| 11 | +enforce_privacy: true |
| 12 | +``` |
| 13 | +
|
| 14 | +Setting `enforce_privacy` to `true` will make all references to private constants in your package a violation. |
| 15 | + |
| 16 | +Setting `enforce_privacy` to `strict` will forbid all references to private constants in your package. **This includes violations that have been added to other packages' `package_todo.yml` files.** |
| 17 | + |
| 18 | +Note: You will need to remove all existing privacy violations before setting `enforce_privacy` to `strict`. |
| 19 | + |
| 20 | +### Using public folders |
| 21 | +You may enforce privacy either way mentioned above and still expose a public API for your package by placing constants in the public folder, which by default is `app/public`. The constants in the public folder will be made available for use by the rest of the application. |
| 22 | + |
| 23 | +### Defining your own public folder |
| 24 | + |
| 25 | +You may prefer to override the default public folder, you can do so on a per-package basis by defining a `public_path`. |
| 26 | + |
| 27 | +Example: |
| 28 | + |
| 29 | +```yaml |
| 30 | +public_path: my/custom/path/ |
| 31 | +``` |
| 32 | + |
| 33 | +### Defining public constants through sigil |
| 34 | + |
| 35 | +> [!WARNING] |
| 36 | +> This way of of defining the public API of a package should be considered WIP. It is not supported by all tooling in the RubyAtScale ecosystem, as @alexevanczuk pointed out in a [comment on the PR](https://github.com/rubyatscale/packwerk-extensions/pull/35#discussion_r1334331797): |
| 37 | +> |
| 38 | +> There are a couple of other places that will require changes related to this sigil. Namely, everything that is coupled to the public folder implementation of privacy. |
| 39 | +> |
| 40 | +> In the rubyatscale org: |
| 41 | +> |
| 42 | +> * pack_stats, example https://github.com/rubyatscale/pack_stats/blob/main/lib/pack_stats/private/metrics/public_usage.rb. (IMO though we can just remove this metric – it has never been useful) |
| 43 | +> * Other places that mention public_path or app/public. |
| 44 | +> * Org wide search for app/public link |
| 45 | +> * Org wide search for public_path link |
| 46 | +> * packs (the Rust port of packwerk – I could take this one over unless someone is interested in implementing whatever we come up with there |
| 47 | + |
| 48 | + |
| 49 | + |
| 50 | +You may make individual files public within a private package by usage of a comment within the first 5 lines of the `.rb` file containing `pack_public: true`. |
| 51 | + |
| 52 | +Example: |
| 53 | + |
| 54 | +```ruby |
| 55 | +# pack_public: true |
| 56 | +module Foo |
| 57 | + class Update |
| 58 | + end |
| 59 | +end |
| 60 | +``` |
| 61 | +Now `Foo::Update` is considered public even though the `foo` package might be set to `enforce_privacy: (true || strict)`. |
| 62 | + |
| 63 | +It's important to note that when combining `public_api: true` with the declaration of `private_constants`, |
| 64 | +`packwerk validate` will raise an exception if both are used for the same constant. This must be resolved by removing |
| 65 | +the sigil from the `.rb` file or removing the constant from the list of `private_constants`. |
| 66 | + |
| 67 | +If you are using rubocop, it may be configured in such a way that there must be an empty line after the magic keywords at the top of the file. Currently, this extension is not modifying rubocop in any way so it does not recognize `pack_public: true` as a valid magic keyword option. That means placing it at the end of the magic keywords will throw a rubocop exception. However, you can place it first in the list to avoid an exception in rubocop. |
| 68 | +``` |
| 69 | +----- |
| 70 | +# typed: ignore |
| 71 | +# frozen_string_literal: true |
| 72 | +# pack_public: true |
| 73 | +
|
| 74 | +class Foo |
| 75 | +... |
| 76 | +end => Layout/EmptyLineAfterMagicComment: Add an empty line after magic comments. |
| 77 | +
|
| 78 | +------ |
| 79 | +# typed: ignore |
| 80 | +# frozen_string_literal: true |
| 81 | +
|
| 82 | +# pack_public: true |
| 83 | +
|
| 84 | +class Foo |
| 85 | +... |
| 86 | +end => Less than ideal. This won't raise an issue in rubocop, however, only the first 5 lines are scanned for the magic comment of pack_public so there is risk at it being missed. It also is requiring extra empty lines in the group of magic comments. |
| 87 | +
|
| 88 | +----- |
| 89 | +# pack_public: true |
| 90 | +# typed: ignore |
| 91 | +# frozen_string_literal: true |
| 92 | +
|
| 93 | +class Foo |
| 94 | +... |
| 95 | +end => Ideal solution. No exceptions from rubocop and very low risk of the magic comment being out of range since |
| 96 | +``` |
| 97 | + |
| 98 | +### Using specific private constants |
| 99 | +Sometimes it is desirable to only enforce privacy on a subset of constants in a package. You can do so by defining a `private_constants` list in your package.yml. Note that `enforce_privacy` must be set to `true` or `'strict'` for this to work. |
| 100 | + |
| 101 | +### Ignore strict mode for violation coming from specific path patterns |
| 102 | +If you want to activate `'strict'` mode on your package but have a few privacy violations you know you will deal with later, |
| 103 | +you can set a list of patterns to exclude. |
| 104 | + |
| 105 | +```yaml |
| 106 | +enforce_privacy: strict |
| 107 | +strict_privacy_ignored_patterns: |
| 108 | +- engines/another_engine/test/**/* |
| 109 | +``` |
| 110 | + |
| 111 | +In this example, violations on constants of your engine referenced in those files `engines/another_engine/test/**/*` will not fail Packwerk checks. |
| 112 | + |
| 113 | +### Package Privacy violation |
| 114 | +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. |
| 115 | + |
| 116 | +#### Interpreting Privacy violation |
| 117 | + |
| 118 | +> /Users/JaneDoe/src/github.com/sample-project/user/app/controllers/labels_controller.rb:170:30 |
| 119 | +> Privacy violation: '::Billing::CarrierInvoiceTransaction' is private to 'billing' but referenced from 'user'. |
| 120 | +> Is there a public entrypoint in 'billing/app/public/' that you can use instead? |
| 121 | +> |
| 122 | +> Inference details: 'Billing::CarrierInvoiceTransaction' refers to ::Billing::CarrierInvoiceTransaction which seems to be defined in billing/app/models/billing/carrier_invoice_transaction.rb. |
| 123 | + |
| 124 | +There has been a privacy violation of the package `billing` in the package `user`, through the use of the constant `Billing::CarrierInvoiceTransaction` in the file `user/app/controllers/labels_controller.rb`. |
| 125 | + |
| 126 | +#### Suggestions |
| 127 | +You may be accessing the implementation of a piece of functionality that is supposed to be accessed through a public interface on the package. Try to use the public interface instead. A package’s public interface should be defined in its `app/public` folder and documented. |
| 128 | + |
| 129 | +The functionality you’re looking for may not be intended to be reused across packages at all. If there is no public interface for it but you have a good reason to use it from outside of its package, find the people responsible for the package and discuss a solution with them. |
| 130 | + |
| 131 | +## Visibility Checker |
| 132 | +The visibility checker can be used to allow a package to be a private implementation detail of other packages. |
| 133 | + |
| 134 | +To enforce visibility for your package, set `enforce_visibility` to `true` on your pack and specify `visible_to` for other packages that can use your package. |
| 135 | + |
| 136 | +```yaml |
| 137 | +# components/merchandising/package.yml |
| 138 | +enforce_visibility: true |
| 139 | +visible_to: |
| 140 | + - components/other_package |
| 141 | +``` |
| 142 | + |
| 143 | +## Folder-Privacy Checker |
| 144 | +The folder privacy checker can be used to allow a package to be private to their sibling packs and parent packs and will create todos if used by any other package. |
| 145 | + |
| 146 | +To enforce folder privacy for your package, set `enforce_folder_privacy` to `true` on your pack. |
| 147 | + |
| 148 | +```yaml |
| 149 | +# components/merchandising/package.yml |
| 150 | +enforce_folder_privacy: true |
| 151 | +``` |
| 152 | + |
| 153 | +Here is an example of paths and whether their use of `packs/b/packs/e` is OK or not, assuming that protects itself via `enforce_folder_privacy` |
| 154 | + |
| 155 | +``` |
| 156 | +. OK (parent of parent) |
| 157 | +packs/a VIOLATION |
| 158 | +packs/b OK (parent) |
| 159 | +packs/b/packs/d OK (sibling) |
| 160 | +packs/b/packs/e ENFORCE_NESTED_VISIBILITY: TRUE |
| 161 | +packs/b/packs/e/packs/f VIOLATION |
| 162 | +packs/b/packs/e/packs/g VIOLATION |
| 163 | +packs/b/packs/h OK (sibling) |
| 164 | +packs/c VIOLATION |
| 165 | +``` |
| 166 | +
|
| 167 | +## Layer Checker |
| 168 | +The layer checker can be used to enforce constraints on what can depend on what. |
| 169 | +
|
| 170 | +To enforce layers for your package, first define the `layers` in `packwerk.yml`, for example: |
| 171 | +``` |
| 172 | +layers: |
| 173 | + - package |
| 174 | + - utility |
| 175 | +``` |
| 176 | +
|
| 177 | +Then, turn on the checker in your package: |
| 178 | +```yaml |
| 179 | +# components/merchandising/package.yml |
| 180 | +enforce_layers: true |
| 181 | +layer: utility |
| 182 | +``` |
| 183 | + |
| 184 | +Now this pack can only depend on other utility packages. |
| 185 | + |
| 186 | +# Enforcement Globs Ignore |
| 187 | +`enforcement_globs_ignore` can be used to specify gitignore-style rules for not enforcing violations. |
| 188 | + |
| 189 | +### Examples |
| 190 | + |
| 191 | +```yml |
| 192 | +# packs/product_services/serv1/foo/package.yml |
| 193 | +enforce_privacy: true |
| 194 | +enforce_visibility: true |
| 195 | + |
| 196 | +enforcement_globs_ignore: |
| 197 | +- enforcements: |
| 198 | + - privacy |
| 199 | + - visiblity |
| 200 | + ignores: |
| 201 | + - "**/*" |
| 202 | + # Enforce incoming privacy and visibility violation references _only_ in `pks/product_services/serv1/**/*` |
| 203 | + - "!packs/product_services/serv1/**/*" |
| 204 | + reason: "It was decided only to fix incoming violations from serv1. See ticket #232" |
| 205 | +``` |
| 206 | +
|
| 207 | +```yml |
| 208 | +# packs/pack2/package.yml |
| 209 | +enforce_dependencies: true |
| 210 | +dependencies: |
| 211 | +# not required because of the below enforcement_globs_ignore |
| 212 | +# - packs/pack1 |
| 213 | +# required because of the enforcement_globs_ignore exception line |
| 214 | + - packs/pack3 |
| 215 | + |
| 216 | +enforcement_globs_ignore: |
| 217 | +- enforcements: |
| 218 | + - dependency |
| 219 | + ignores: |
| 220 | + - "**/*" |
| 221 | + # Enforce outgoing dependency violation references _only_ to `pks/pack3/**/*` |
| 222 | + - "!packs/pack3/**/*" |
| 223 | + reason: "The other dependency violations are fine as those packs will be absorbed into this one." |
| 224 | +``` |
| 225 | +
|
0 commit comments