Flipping the meaning of `enforce_privacy`?
shageman opened this issue · 4 comments
[EXPLORE]
Hi all!
I have been spinning the wheels on packwerk and love it so far!
Regarding privacy - when listing privacy constraints by constant, I would like to list the public files in the config so any new constants are private by default. Right now I can only use enforce_privacy which will make new constants public by default. With the new name I propose, enforce_api_boundary, the behavior of true could stay the same.
Is this something you would accept a PR for?
I think your reasoning makes sense to me, and I would accept it, but I know that @exterm has a few opinions about privacy enforcement. So I would like him to chime in as well
If you want to list public constants, can't you just put their definitions into the public folder?
The design intention is for the public folder to serve this purpose; the list in the package manifest is a workaround specifically for packages that are not yet ready to enforce privacy on everything; it's a way to ignore the "the grey area" (constants that probably shouldn't be public, but may have to be).
I think it is fair to say that we are to some extent still exploring the implications of concept-based folder structures backed by packwerk. One thing that makes it relatively easy to sell is that the folder and configuration changes are in fact minimal. Still, moving things out of the default folder structure raises questions for some. I should add that packwerk is a development dependency on for us, which helps.
Having the option to specify a public API that sits in front of a "private by default" package with the constant list would allow us to explore more about what packwerk's implications are without moving more files around (i.e., make this exploration have impact on development only).
I understand. However, my assumption has always been that visibility reflected in folder structure makes sense in a system built on folder structure (folder structure determines which package code is in).
The use of enforce_privacy with a list of constants was introduced later when we found that for most of our legacy code, setting enforce_privacy to true would only be possible after a major refactor, during which packwerk would not be helpful to prevent regressions.
It wasn't intended as a paradigm shift away from the folder structure based semantics.
To be perfectly honest, I'm not sure that right now we have the bandwidth to make a decision like this, as we're intentionally focusing on other things and packwerk works "well enough" for our use cases. But let's see, maybe we can figure something out.
make this exploration have impact on development only
Are you concerned about load order issues arising from moving files? Other than that, there should not be a production impact from moving files around between autoloaded folders, as long as naming & namespacing stays the same.
I would like to understand your use case better.
BTW, something that we've done internally as a hack to get something resembling "privacy by default" without setting enforce_privacy: true is to enforce privacy on a namespace and put all new code into that namespace (e.g. Private).