Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup #351

Merged
merged 37 commits into from
Dec 18, 2017
Merged

Cleanup #351

merged 37 commits into from
Dec 18, 2017

Conversation

kulshekhar
Copy link
Owner

@kulshekhar kulshekhar commented Oct 21, 2017

Following the discussion in #349

All I've done so far is

  • remove __TS_CONFIG__ related stuff
  • rename some variables/parameters for clarity
  • move some functions, that are only used in our tests, from utils.ts to a new file test-utils.ts

closes #394
closes #395
closes #396

);
}
result = converted.options;
if (configPath === path.join(getStartDir(), 'tsconfig.json')) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this to ensure that if the file is just called tsconfig.json we overwrite the module, and if it's called something like tsconfig.test.json we expect people to know what they're doing? I like the idea, but I feel like it could lead to trouble.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thought process was that because most people don't create a custom tsconfig for testing, it's safe to override the module to commonjs during testing. But if they do have a custom tsconfig, they're more likely to have thought through what they want and any module change they made should be used

@GeeWee
Copy link
Collaborator

GeeWee commented Oct 31, 2017

I wasn't quite sure how to proceed with this - as I wanted to comment on some code that wasn't in a diff. I settled for adding TODO's - as they're easy to find.

I didn't want to change your branch, but I figured it was the easiest way to get some talking points down. Overall I think this looks really promising.

What are your thoughts?

@kulshekhar
Copy link
Owner Author

kulshekhar commented Nov 1, 2017

/* TODO: Consider inlining tsJestConfig here, so it's obvious it's only used here. Actually seeing as tsJestConfig

Consider inlining tsJestConfig here, so it's obvious it's only used here.

I see your point. I normally don't like to place function calls as arguments but since the arguments here are on new lines, I don't see much of a problem in doing this.

Actually seeing as tsJestConfig
is contained withing jestConfig, perhaps we should just have the getPostProcessHook extract it itself?

I think passing in the config makes it easier to debug (and add tests) getPostProcessHook should we have to.

// TODO: Comment what's going on here. I'm not quite sure why we're adding this if it's an html file

This was added in a PR to support angular 2+

// TODO: Consider flipping this boolean to exit-early if we don't want to process the file.

yeah, something like if (!processFile) return src right after fetching compilerOptions? I agree that this would make the code cleaner.

EDIT: Actually, it might just be better to move the creation of the postHook to the point where it is used, AND flip the boolean

// TODO: Consider creating a function for this part? e.g. prependSourcemapHook()

Agreed.

// TODO: This can take something more specific than globals

If we try to use something more specific (e.g. globals['ts-jest']), we'll have to do a null check on globals from wherever we call this function. I think the current state is a cleaner alternative

// TODO: Perhaps rename collectCoverage to here, as it seems to be the official jest name now:

instrument doesn't seem as clear as collectCoverage in the context of this function.

- inline the call to get ts-jest configuration
- flip the check on the file type
- extract the injection of the sourcemap hook into a function
@GeeWee
Copy link
Collaborator

GeeWee commented Nov 2, 2017

I think passing in the config makes it easier to debug (and add tests) getPostProcessHook should we have to.

Fair enough.

This was added in a PR to support angular 2+

Can we link to the issue perhaps?

yeah, something like if (!processFile) return src right after fetching compilerOptions? I agree that this would make the code cleaner.
EDIT: Actually, it might just be better to move the creation of the postHook to the point where it is used, AND flip the boolean

Yeah something like that sounds good.

Let me know when I should take another look or if you want me to do some of the heavy lifting

@kulshekhar
Copy link
Owner Author

Let me know when I should take another look or if you want me to do some of the heavy lifting

I've already incorporated the earlier feedback. If you could add the link to the angular issue/PR, this PR would be in sync with our understanding of how things should be.

@GeeWee
Copy link
Collaborator

GeeWee commented Nov 3, 2017

I've done that!

@kulshekhar
Copy link
Owner Author

Looks like the build is failing on Linux for Node 4.

Can you revert the tslint bit from this PR? That's unrelated to the cleanup and can be a separate PR, right?

@kulshekhar
Copy link
Owner Author

Looks like the build is failing on Linux for Node 4.

Can you revert the tslint bit from this PR? That's unrelated to the cleanup and can be a separate PR, right?

@GeeWee

@GeeWee
Copy link
Collaborator

GeeWee commented Nov 7, 2017

Strange - yeah I just stumbled upon it as an annoyance when I was fixing something else.

I've removed the rule.

GeeWee
GeeWee previously approved these changes Nov 8, 2017
Copy link
Collaborator

@GeeWee GeeWee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm - not sure we should merge this in before our next major release - is there a chance we'll break things?

@kulshekhar
Copy link
Owner Author

We shouldn't merge this before the next major release - this PR removes support for __TS_CONFIG__

@GeeWee
Copy link
Collaborator

GeeWee commented Nov 9, 2017

Good point. Nice work on this.

@kulshekhar
Copy link
Owner Author

@GeeWee this update seems to have broken something in hoisting. I've Skipped that test for now.

Can you please take a look?

@kulshekhar
Copy link
Owner Author

@GeeWee don't worry about it. Turns out, it was a bug in jest

@kulshekhar kulshekhar changed the title [WIP] Cleanup Cleanup Dec 18, 2017
@kulshekhar kulshekhar merged commit c610c13 into master Dec 18, 2017
@kulshekhar kulshekhar deleted the cleanup branch January 30, 2018 23:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants