"Strict" mode to enforce_dependencies and enforce_privacy

[alexevanczuk]

At Gusto we have some custom tooling to help packages that have solidified their boundaries (i.e. addressed all of their incoming privacy violations and outgoing dependency violations) keep those boundaries solid. This tooling allows users to configure, on a per-pack basis, no longer allowing any new violations.

I was wondering if folks would find this useful and be open to this being a part of packwerk:

enforce_privacy: strict
enforce_dependency: strict

It behaves just like true, except that it will not allow bypassing by adding to deprecated_references.yml (you first would need to downgrade from strict to true). This could work within bin/packwerk check or the new behavior could be a validation in bin/packwerk validate. I think the former is probably better to give users faster feedback, but either could work!

[mclark]

Although GitHub is still a long way off from using this, I really like the idea! My only concern is that enforce_privacy currently also supports a list of strings indicating specific constants for which we want to enforce privacy. It is starting to feel a bit crowded under this name! 😄

Putting aside backward compatibility concerns for now, I feel the ideal arrangement here would be something like this:

enforce_privacy: [false|true|strict|]  # (ascending order of enforcement, defaults to false)
private_constants:
  - "::Merchandising::Product"
  - "::SomeOtherConstant"

Adding any private_constants would need to either implicitly bump enforce_privacy to true at least, or require it to be explicitly set by the user.

[alexevanczuk]

This makes sense to me as an API change. My hope with privacy is to extract it out in a way that 100% preserves the behavior and API. Once I've done that, I'd like to start a discussion there with folks who use the privacy plugin on where we should take its public API 🙏

From the perspective of packwerk having a plugin system, the "strict" aspect would be something that would be part of the checker interface and enforced by packwerk. How the checker actually knows that its strict or not would be something each checker could configure, but I'm hoping that enforce_x: [false|true|strict|] could be a common standard!

[mclark]

enforce_x: [false|true|strict|] could be a common standard!

Oh I like that!

[alexevanczuk]

Implementation proposal: #271

[nilbus]

Since this was merged, could this be accepted as the answer to mark this discussion as "answered"?