it’s just that my personal flags package also imports the parse package for constants
so i can either refactor and make it so that the flags package doesn’t have control of anything in the parse package, which makes parsing flags slightly less convenient
or i can refactor all shared constants into a separate pacakge
i don't see an issue with moving just constants to a shared package. this sounds like the start to every "slippery slope" type setup but i think if we're disciplined about it, it shouldn't be an issue
bu tmaybe im naive
do you know what i mean by slippery slope? its kinda like controllers in an MVC app
so i think the responsible thing is to refactor rather than to create another shared package
shared constants package has its own limitations
storing all configuration in exactly one place is bad
being modular and having things manage themselves entirely is the goal of reducing overly complex responsibility patterns
so in reality, i have myself to blame
however - when i originally designed it, i didn’t plan on taking advantage of the flags package in order to exploit shit in order to actually reduce complexity