What are the use-cases for the visibility checker vs. dependencies?

[Skipants]

Maybe I'm not grok'ing it totally, but to me the following two package.yml examples seem to be the same, just inverted:

Example A (The visibility checker example on README.md)

# components/merchandising/package.yml
enforce_visibility: true
visible_to:
  - components/other_package

vs. Example B

# components/other_package/package.yml
enforce_dependencies: true
dependencies:
  - components/merchandising

Am I correct that they are the same or am I missing something? Why would I use Example A over Example B which is part of packwerk core?

Thanks!

[alexevanczuk]

Hey @Skipants thanks for raising the question!

In example B, components/other_package will have a dependency violation if it uses a package without a dependency.
In this case, it's other_package's responsibility to make sure that it's only using packages it has an explicit dependency on.
In this case, it does not matter if the package it uses states it is "visible to" other_package – it's a dependency violation nonetheless.

In example A, merchandising creates a visibility violation in other_package even if it's listed as a dependency.

You're right that these two examples produce the same signal (i.e. a violation). The main differentiating factor here is that visibility lets a package say "only these packages can use me," which may be useful if a package is an implementation detail of another one. Visibility is useful for a package to restrict what other packages can depend on it, rather than what packages it can depend on.

In general, the dependency checker is more broadly applicable than visibility.

Let me know if this answers your question or if you have any follow-ups!

[Skipants]

Thanks for the answer @alexevanczuk! I think I see it, now. So if we had these two package.yml files in the same application:

# components/merchandising/package.yml
enforce_visibility: true
visible_to:
  - components/other_package

# components/some_third_package/package.yml
enforce_dependencies: true
dependencies:
  - components/merchandising

This will still throw a dependency violation if some_third_package uses a constant from merchandising because, in a way, the list of packages in visible_to overrides it. Makes sense. Thanks again!