Message originally sent by slack user U71810IPUMS
And it definitely is a design/architectural problem.
Message originally sent by slack user U71810IPUMS
I am hopeful that packwerk may be able to help change the architecture to something better suited to solving this problem.
Message originally sent by slack user U71810IPUMS
And thank you for your patience. I am trying my best to convey this better.
Message originally sent by slack user U71810IPUMS
In short, we sometime have client specific code that needs to override the standard code for a feature. We currently place this in a client specific folder and when calling a feature’s public API reference a manually updated register to check if a version of the feature exists in the client specific folder or fallback to the standard implementations.
Message originally sent by slack user U71810IPUMS
This manually updated register is very error-prone, difficult to read, and overall not well designed.
Message originally sent by slack user U71810IPUMS
As such, I was curious if this is a problem that has already been solved by packwerk, could be solved using packwerk, or if anyone in the community has heard or a better architecture/design for solving the problem?
Packwerk’s strong point is really just allowing you to constrain the public API and dependencies of a folder of code. The hard part here is figuring out what design (what packs, what public API, and what dependencies) will solve your problem. Packwerk can give you a TODO list to help you achieve that design, but its totally up to you to figure out what design will solve this problem for you.