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

Fix decorators on windows by adjusting implicit jest path based on OS #324

Merged
merged 2 commits into from
May 12, 2018

Conversation

ThomasRooney
Copy link
Collaborator

@ThomasRooney ThomasRooney commented May 12, 2018

The green/red dots are currently broken on windows if jest path isn't configured.

The jest path selected is always a shell jest (linux/mac) script, rather than a feature based on current operating system, and potentially running the jest.cmd file. As such it crashes when attempting to run in windows ENOENT, because windows cannot evaluate shell scripts.

This fixes that.

  • Removed double default configuration in package.json and in pathToJest helper
  • Check for OS platform before deciding on which script to run
  • Assumes global jest if jest not in node_modules.

Not tested on Mac/Linux. Please confirm this doesn't regress there if you decide to merge.

This closes quite a few bugs that are correlated because the jest --getConfig command wasn't working on windows. FYI for a current workaround, just define jest path explicitly.

Closes #274 #320 #306 #289

@ThomasRooney ThomasRooney changed the title Hotfix/windows jest location Make decorators work on windows by fixing implicit jest path May 12, 2018
@ThomasRooney ThomasRooney changed the title Make decorators work on windows by fixing implicit jest path Fix decorators on windows by adjusting implicit jest path on operating system platform May 12, 2018
@coveralls
Copy link

Pull Request Test Coverage Report for Build 357

  • 1 of 8 (12.5%) changed or added relevant lines in 1 file are covered.
  • 2 unchanged lines in 1 file lost coverage.
  • Overall coverage decreased (-1.06%) to 74.168%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/helpers.ts 1 8 12.5%
Files with Coverage Reduction New Missed Lines %
src/helpers.ts 2 39.29%
Totals Coverage Status
Change from base Build 353: -1.06%
Covered Lines: 570
Relevant Lines: 734

💛 - Coveralls

@ThomasRooney ThomasRooney changed the title Fix decorators on windows by adjusting implicit jest path on operating system platform Fix decorators on windows by adjusting implicit jest path based on OS May 12, 2018
@orta
Copy link
Member

orta commented May 12, 2018

Yeah, cool, this looks 👍 to me - thanks!

@orta orta merged commit 6b3ad5e into jest-community:master May 12, 2018
@stephtr
Copy link
Member

stephtr commented May 17, 2018

I think in the end that differentiation between Windows and Unix shouldn't be necessary if jest runs in a shell everywhere. Maybe even #297 would fix the problem (and would also fix #313), that PR however still waits for a new release of Jest.

@@ -61,15 +61,24 @@ function hasNodeExecutable(rootPath: string, executable: string): boolean {
* @returns {string}
*/
export function pathToJest(pluginSettings: IPluginSettings) {
const path = normalize(pluginSettings.pathToJest)
if (pluginSettings.pathToJest) {
Copy link
Member

Choose a reason for hiding this comment

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

What's your intention for changing this line @ThomasRooney? It seems to me like we've changed it from "if this is still the default setting" to "if the default setting has changed".

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I removed the default setting for pathToJest From the package.json. I did this because I didn’t want to break any user configuration where they’d predefined it, but the default pathToJest defined before was incorrect for windows systems (forcing Windows users to explicitly define it).

With pathToJest now potentially being null, I wanted to maintain old behaviour for linux/osx users, and my interpretation is that each code path used for the old version is equivalent in the new version, but for the windows scenario. In this particular line, I’m mapping the path !== defaultPath scenario for OSX users, which returned normalize(pluginSettings.pathToJest).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

E.g. path === defaultPath => either npm test — or normalize(‘node_modules/.bin/jest’)
path !== defaultPath => normalize(path)

@stephtr
Copy link
Member

stephtr commented May 21, 2018

One serious effect of that change is, that the detection for CRA apps now only takes place, when jest.pathToJest is already manually set, by default it fails!
As #297 finally fixes #274 I would revert or further update pathToJest (as done within #297).

@ThomasRooney
Copy link
Collaborator Author

@stephtr good point! This additional condition came from path === defaultPath && isBootstrappedWithCRA(pluginSettings.rootPath) but the path === defaultPath is equivalent to path not being predefined, instead of path being predefined. The CRA condition should be taken outside the nested if.

However my understanding of #297 is it would break windows again, because even if jest supports a different shell, the node_modules/.bin/jest is the bootstrap of jest that we invoke, and requires be run in a bourne-complaint shell (i.e. it will crash if run as a windows bat file). Please correct me if I'm wrong?

@stephtr
Copy link
Member

stephtr commented May 21, 2018

By starting the commands in a Windows cmd (simply by supplying { shell: useShell }), running node_modules/.bin/jest automatically runs node_modules\.bin\jest.cmd (that's the same as omitting the .exe extension of a file when running it). The issue was that the runner itself ran the command in a cmd, but not the settings when fetching Jest's configuration after launch.

@seanpoulter
Copy link
Member

I’ve got a PR in progress if you can wait another half day. 🐌

legend1202 pushed a commit to legend1202/vscode-jest that referenced this pull request Jun 18, 2023
…s-jest-location

Fix decorators on windows by adjusting implicit jest path based on OS
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.

Bug: Spawning Jest on Windows with jest-editor-support < 22.1.3
5 participants