This is an interesting issue because we need to consider if we prefer code duplication, more complex dependencies, or a refactor which would be quite odd.
Option One: Code Duplication
We copy paste all the code from querySuggest to scheduleSuggest.
This is certainly the easiest to understand but means that when we have to update that code (we will), we'll end up right back here where something is supported in one but not the other.
Option Two: More Complex Dependencies
We have scheduleSuggest call directly into querySuggest.
This is the most expeditious thing to do, and it has no code duplication. The issue here is that now commands can rely on other commands in hard to reason about ways. I can't think of a time where editing querySuggest would cause problems with scheduleSuggest but the fact that a developer might not realize that is sub optimal.
Option Three: A Refactor
We take our query suggestion code and refactor it out into another file or module.
This solves both the above problems which is good, but creates a new question: where would that code live? Where ever it is, it needs access to the hosts module so there might be some reason to put it there. Utils is much lower level and would probably create a circular dependency between utils and hosts. We could create a command utils, but it seems such a function would be useful even outside of commands, along with conceptually not fitting.
I tend to think that Option Two is the best one here but I think that Option Three also needs to be strongly considered. Option One is definitely out though.
This is an interesting issue because we need to consider if we prefer code duplication, more complex dependencies, or a refactor which would be quite odd.
Option One: Code Duplication We copy paste all the code from querySuggest to scheduleSuggest.
This is certainly the easiest to understand but means that when we have to update that code (we will), we'll end up right back here where something is supported in one but not the other.
Option Two: More Complex Dependencies We have
scheduleSuggestcall directly intoquerySuggest.This is the most expeditious thing to do, and it has no code duplication. The issue here is that now commands can rely on other commands in hard to reason about ways. I can't think of a time where editing
querySuggestwould cause problems withscheduleSuggestbut the fact that a developer might not realize that is sub optimal.Option Three: A Refactor We take our query suggestion code and refactor it out into another file or module.
This solves both the above problems which is good, but creates a new question: where would that code live? Where ever it is, it needs access to the hosts module so there might be some reason to put it there. Utils is much lower level and would probably create a circular dependency between utils and hosts. We could create a command utils, but it seems such a function would be useful even outside of commands, along with conceptually not fitting.
I tend to think that Option Two is the best one here but I think that Option Three also needs to be strongly considered. Option One is definitely out though.