Fork me on GitHub
#clj-kondo
<
2024-02-15
>
mkvlr09:02:35

do folks have a workflow to deprecate a var without having to immediately refactor all current usages (but not introduce new ones)?

borkdude09:02:32

you mean with respect to kondo linting?

phill10:02:41

Refactor first and deprecate second?

mkvlr10:02:33

deprecate second would work but then I might as well remove it alltogether

mkvlr10:02:09

was wondering if there’s any approaches to ensure at least no new code is added that uses it in the meantime

mkvlr10:02:17

and that encourages a gradual migration

borkdude10:02:39

I don't know if "yes" was an answer to my or phill's question. Can you please state the question without any ambiguitiy?

mkvlr10:02:38

my question is if there’s any clj-kondo based approaches folks are using to deprecate a var with the help of clj-kondo

mkvlr10:02:56

meaning I want linting to fail if new usages of a var are introduced

mkvlr10:02:14

but have it not complain about the existing usages

mkvlr10:02:06

this is a closed source project so there’s no need to keep the var around once it’s unused

borkdude10:02:26

clj-kondo doesn't have the concept of "vars used since $timestamp" but what you can do is filter out the warnings that exist at $timestamp

mkvlr10:02:04

one thing I can think if is have a more strict linter settings for files you touch

mkvlr10:02:10

like in a pre-commit hook

borkdude10:02:25

true, but in that file there could also be old usages of that var

mkvlr10:02:38

> what you can do is filter out the warnings that exist at $timestamp how could that work?

borkdude10:02:19

> how could that work? This approach has been used before by nextjournal I think, just keep track of the existing warnings at $timestamp and "subtract" those from new warnings

mkvlr10:02:39

oh, need to dig it up

mkvlr10:02:49

maybe it’s also too complex and I’m overthinking things

borkdude10:02:57

Honestly I think it would be easier to migrate to the new var

mkvlr10:02:28

the var in question is dissoc-nil-vals btw. We use it quite a bit when creating datomic transaction maps. What I don’t like about it that it hides what can and can’t be nil. I’d like to refactor it to cond-> but if you think something is mandatory and it’s actually optional we get transaction failures…

borkdude10:02:01

@U5H74UNSF is this function only used in that project or also in other libs?

mkvlr10:02:40

only in that project

borkdude10:02:21

if it's only in the project, you could do this: rename the function to dissoc-nil-vals-DEPRECATED-no-longer-use-this (using clojure-lsp or IntelliJ or any other tool that can rename vars properly). Then it will become very obvious in code review that you should not introduce new usages of this var

1
mkvlr10:02:29

coming onboard with that it’s better to remove it, should at least do a spike and try

mkvlr10:02:43

ah yeah, nice, that’ll work

mkvlr10:02:27

nice and simple, thanks!

👍 1