Ts-jest: Refactor code

[kulshekhar]

We've been fixing things and adding features and the relative ad hoc manner seems to have taken its toll on the readability of the code. The code has become quite unwieldy.

The refactor might just end up being moving around functions and adding some comments but it could also be a serious rewrite. This could coincide with the move to version 22 when we'll be taking out __TS_CONFIG__ related stuff which alone should result in some code/test removal

Need to put some thought into it so that we don't have to go through something like this too soon down the road.

[GeeWee]

Yeah I've been thinking about this for a while too. Completely agree.

[morajabi]

Ah, I think we can structure methods and helpers better and rename files.

[kulshekhar]

I don't want to be too hasty here. We shouldn't decide on what to do before we identify the problem areas.

[morajabi]

@kulshekhar Sorry! So I should mention I had a semi-hard time to figure out different pieces of project at my first PR!

[kulshekhar]

I should mention I had a semi-hard time to figure out different pieces of project at my first PR

That's what I'd like to address in this issue.

From a high level, there seem to be too many conditional branches that make it difficult to visualize what's happening at any given point in the code (or predict what the effect of a change might be).

What I'd like (ideally) is to see if there's a way to decouple these conditions and isolate each of them in their own containers so that the code reads linearly and all the complexity is bundled away in self contained bits of code.

I'm not sure if I've put this in a way that makes sense. I'm trying to see if I can find some time to crystallize my thoughts into something more understandable :)

[kulshekhar]

To begin, I think we should make a list of all the edge cases that we're handling and how they affect each other. We can then decide if and how we need to move forward

[GeeWee]

I agree with the decoupling. Currently, e.g. we get a tsconfig, and then we parse it, and then we muck a bit around with changing some defaults depending on some other defaults - it does get a little confusing.

[kulshekhar]

yeah.

Having removed the unused stuff and dividing the util code into two parts seems to have cleared some things up for me. The changing of defaults is happening at one place (in the function to fetch tsconfig) so it seems kinda alright for now

[GeeWee]

Sounds good! Let me know when you want me to take a look at the branch.

[kulshekhar]

Let me know when you want me to take a look at the branch.

I think it's now in a state where it's easier to analyze the code and determine what changes (if any) will improve maintainability. So any time from now till Jest publish v22 would be a good time :)