-
Notifications
You must be signed in to change notification settings - Fork 455
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
Cleanup #351
Conversation
); | ||
} | ||
result = converted.options; | ||
if (configPath === path.join(getStartDir(), 'tsconfig.json')) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
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? |
Line 24 in 9cfd056
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.
I think passing in the config makes it easier to debug (and add tests) getPostProcessHook should we have to. Line 33 in 9cfd056
This was added in a PR to support angular 2+ Line 41 in 9cfd056
yeah, something like EDIT: Actually, it might just be better to move the creation of the Line 57 in 9cfd056
Agreed. Line 96 in 9cfd056
If we try to use something more specific (e.g. Line 118 in 9cfd056
|
- 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
Fair enough.
Can we link to the issue perhaps?
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 |
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. |
I've done that! |
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? |
|
Strange - yeah I just stumbled upon it as an annoyance when I was fixing something else. I've removed the rule. |
There was a problem hiding this 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?
We shouldn't merge this before the next major release - this PR removes support for |
Good point. Nice work on this. |
@GeeWee this update seems to have broken something in hoisting. I've Skipped that test for now. Can you please take a look? |
@GeeWee don't worry about it. Turns out, it was a bug in jest |
Following the discussion in #349
All I've done so far is
__TS_CONFIG__
related stuffutils.ts
to a new filetest-utils.ts
closes #394
closes #395
closes #396