Fork me on GitHub

A cautionary tale about refactoring legacy code to Polylith! In our legacy code, we have a number of auto-resolved keywords like ::foo and then they are referred to as ::alias/foo in code outside that namespace. When you refactor that code to Polylith, the ns changes -- which is fine if the keyword is used in the interface since that's what the other code will :require (`:as alias`) so ::alias/foo will continue to work. However, if the keyword is instead used in the implementation, the alias doesn't point to that so the usage will resolve to :top-ns.some-brick.interface/foo but the actual keyword usage inside that brick will auto-resolve to :top-ns.some-brick.impl/foo... Ooops! Two bugs caused by that mistake went to production (for ~24 hours) after a large refactor to Polylith over the last two weeks. It's probably "better style" to not use auto-resolved keywords outside their "home" ns and instead use :explicit/foo qualified keywords for ones that are used across multiple nses.

👍 4
💡 3
Daniel Gerson13:09:21

Thanks. So just to be clear the ::alias/foo now resolves incorrectly to the interface leaving the real implementation version unreferenced. Feels like a space for tooling to lint unreferenced keywords.


Yup. And in our case it meant the code adding options to a hash map was using a different key to the impl code retrieving options from that hash map -- so it behaved as if the options were not set.

👍 1
Pragyan Tripathi08:09:29

I encountered this issue while writing our software. We were forced to use :explicit-namespace/keyword instead of fully qualified keywords.