Allowing public constants without adding dependencies within packages

[bschrag620]

We have just begun the journey of implementing packwerk and I'm really excited for how I think it will help us to reinforce better practices. I've only begun playing around with it in some sample projects and I feel like there some potential for another option in package.yml. I believe some of the conversation in issue 2 is related.

It feels like there should be a way to allow communication between packages with

1. the sending package requiring the receiver as a dependency or
2. the receiving package enforcing privacy

I think a possible solution to this is to allow for publically_enforced_dependencies to be defined in package.yml. Take the following 2 packages:

# /packages/foo/package.yml
enforce_dependencies: true

publically_enforced_dependencies:
 - packages/bar


# /packages/bar/package.yml
enforce_dependencies: true

Taking an example folder structure for package/bar as follows:

app
|-  public
|--  bar
|----  fetch.rb
|-  services
|--  bar
|----  something_private.rb

Foo package would be able to call Bar::Fetch without any violation, but referencing Bar::SomethingPrivate would be flagged as a violation.

For me, and again we are just beginning this journey so my experience is essentially nil, is that the current approach seems like organizations trying to migrate their legacy code are faced with either a very large amount of deprecated references to deal with. Through this approach I think there is a path that allows a team to more easily avoid excessive warnings and still be on the path toward a nicely modularized system. I even feel like this is potentially a very nice end state as well - packages can speak freely to one another through their public interface without the need for explicit dependencies on one another.

I've began dabbling a bit with a custom checker and validator for this purpose and am happy to submit the work if it feels like a good option.

[alexevanczuk]

Hey @bschrag620 thanks for the issue. I'm not sure I'm understanding mixing the privacy and dependency concerns. We've thought of them as independent responsibilities.

There is a mechanism available currently which may help you focus on specific violations over other. You can set "ignored_private_constants" in the pack that is enforcing privacy to exclude certain constants. Dependency doesn't yet have a similar feature available (although at Gusto we added "ignored_dependencies" to an overridden dependency checker), but there's always the possibility of turning off the enforcement until you're ready to handle the violations.

Let me know your thoughts!

[bschrag]

It seems like it could be a good option for foo to be able to claim a dependency but ensure that it is only relying ob public constants without the need for it's dependencies to claim privatization and whitelist their public constants.

My more specific use case is that we what might we will be creating some brand new models, controllers, etc as packages or engines. This net new code will need to interact with the "legacy" and it feels like it could be nice to implicitly add a few small public APIs to legacy but placing the necessary code in a public folder. After saying all of that, perhaps ignored private constants config does fit the need. I think what is missing though is there isn't an explicit dependency between the new code and the old code (or other packages that utilize the ignored private pattern). The proposed approach would still have an explicit dependency but keep it's interactions scoped.

[alexevanczuk]

Thanks for providing some additional context. I think overall I'm confused because today, privacy checking and dependency checking are totally independent. That is – nothing you do to resolve a dependency violation should affect whether something is a privacy violation, and vice versa. I still don't fully understand the change in behavior that relates the two and since they're independent, you should have strictly more options to affect the configuration compared to if they are coupled.

Perhaps what might help me better understand is if you can present a scenario where the new paradigm would affect behavior in a way that is not possible with independent privacy and dependency checking. In the above example, we are able to configure privacy and dependency separately to achieve the goals.

[bschrag620]

Here's a possible example - and perhaps I'm just getting ahead of myself in thinking through potential package structures:

packages:
|-  parent
|--- child
|-  foo

Now this child package is going to rely on the parent package. However, foo needs access to parent but we don't want to grant it full access/dependency. Instead, we want foo to have access to only public constants/services/etc. That is that foo has a dependency that is only scoped to publicly accessible code.

As I type all this out, I'm not sure I'm even agreeing with the original idea any more. It kind of feels more like a suggestion to only help minimize violations while in transition between a current and end state. Since there is a path for handling violations it is seeming best to just stick to it.

[alexevanczuk]

If we're talking about having foo only access the public API of the parent class – there is a checker that might be more of use to you. Namely – the visibility checker.

In packages/parent/child/package.yml, you could specify enforce_visibility: true and visible_to: ['packages/parent]`.

This should express what you're trying to say. In conjunction with the dependency checker and privacy checker, you should be able to express what you're trying to. Likewise, I could understand the desire for an abstraction that encapsulates all these ideas with less configuration – I'm just not sure what that abstraction is yet (probably related to nested packs specifically, cc @shageman)