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

Add usage of shell when creating Settings #297

Closed
wants to merge 8 commits into from
Closed

Add usage of shell when creating Settings #297

wants to merge 8 commits into from

Conversation

stephtr
Copy link
Member

@stephtr stephtr commented Apr 5, 2018

This change will finally close #274. We still have to wait until jest/#5658 and jest/#6212 get released to npm, but in the meantime I created this PR so that we don't forget about it.
#trivial

@coveralls
Copy link

coveralls commented Apr 5, 2018

Pull Request Test Coverage Report for Build 389

  • 9 of 9 (100.0%) changed or added relevant lines in 2 files are covered.
  • 2 unchanged lines in 1 file lost coverage.
  • Overall coverage increased (+3.3%) to 78.952%

Files with Coverage Reduction New Missed Lines %
src/JestExt.ts 2 53.47%
Totals Coverage Status
Change from base Build 383: 3.3%
Covered Lines: 661
Relevant Lines: 811

💛 - Coveralls

@stephtr
Copy link
Member Author

stephtr commented May 21, 2018

I updated jest-editor-support to the last beta (23.0.0-charlie.2), since there haven't been made any large changes except our fixes.

@seanpoulter
Copy link
Member

I hate to be asking it at this point in your PR but can you explain why we need another shell option in jest-editor-support? Is it explained in the issues you linked? Having that in two places seems like a code smell that we should clean up in jest-editor-support.

@stephtr
Copy link
Member Author

stephtr commented May 22, 2018

No problem. You actually introduced the second occurence with Jest#5658 😉. The issue is that if we would like to omit the .cmd extension, we have to run the command in a shell every time. jest-editor-support creates a Jest process in Runner#L83, Runner#L136 and Settings#L66. With Jest#5340 and vscode-jest#248 we fixed the first two occurrences, but forgot about the third one (which resulted in #274).

Since Runner and Settings are independent from each other, a cleaner solution than supplying shell two times would be hard. The only option I could think of would be to move shell: platform() === 'win32' directly into Process#L48 such that we don't have to care about it in vs-code anymore.

@seanpoulter
Copy link
Member

Sweet, thanks for those links and details. Since they're all using this._createProcess from the Process we could wrap that to set our common shell option on our end of Process, but those still all end up in the constructor options and aren't any cleaner. 🤔

Copy link
Member

@seanpoulter seanpoulter left a comment

Choose a reason for hiding this comment

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

Two blocking comments:

  • We're rolling back @ThomasRooney's Windows support. I can see how that might not be a problem if we get this in and v23 doesn't explode.
  • The warning message might be a bit much when Jest is globally installed or running from a monorepo

@@ -20,7 +20,8 @@ export function registerSnapshotCodeLens(enableSnapshotPreviews: boolean) {

class SnapshotCodeLensProvider implements vscode.CodeLensProvider {
public provideCodeLenses(document: vscode.TextDocument, _token: vscode.CancellationToken) {
const snapshots = new Snapshot()
// temporarily use `undefined` as parser argument, until Jest/#6212 is published
const snapshots = new Snapshot(undefined)
Copy link
Member

Choose a reason for hiding this comment

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

How do you feel about adding another line to the comment explaining when we can remove the argument? It'd be quick for someone who sees it to test it and see if the type updated type definition with the optional arg has been published with jestjs/jest#6212.

Copy link
Member Author

Choose a reason for hiding this comment

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

My plan was to remove it by myself as soon as there is a new release of Jest (I had it written to my calendar), but since jest-editor-supportv23 already includes that change, the undefined parameter won't be necessary anymore.

"type": "string",
"default": null
"default": ""
Copy link
Member

Choose a reason for hiding this comment

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

One of us is going to have a failing test if this changes. 😉

@@ -259,7 +261,8 @@ export class JestExt {
this.workspace.pathToJest = pathToJest(updatedSettings)
this.workspace.pathToConfig = pathToConfig(updatedSettings)

this.jestSettings = new Settings(this.workspace)
const useShell = platform() === 'win32'
this.jestSettings = new Settings(this.workspace, { shell: useShell })

Copy link
Member

Choose a reason for hiding this comment

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

Seeing the same thing twice makes me think we should move this into one spot:

updateSettings(workspace) {
  this.jestSettings = new Settings(workspace, { shell: platform() === 'win32' })
}

Copy link
Member Author

Choose a reason for hiding this comment

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

I at first just thought of moving the settings out into its own property (a la this.settingsOptions = { shell: platform() === 'win32' }, but your approach is tidier than that.


const defaultPath = normalize('node_modules/.bin/jest')
if (existsSync(join(pluginSettings.rootPath, defaultPath))) {
return defaultPath
Copy link
Member

Choose a reason for hiding this comment

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

This would remove the check for jest.cmd and fail on Windows systems.

Copy link
Member Author

Choose a reason for hiding this comment

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

This wouldn't fail since on Windows both files, 'node_modules/.bin/jest' and 'node_modules/.bin/jest.cmd' are present. But if we already check for the existence of the file, we probably really should keep caring about the extension.

}

vscode.window.showWarningMessage("Jest couldn't be found. Maybe you forgot to run `npm install`?")
return 'jest'
Copy link
Member

Choose a reason for hiding this comment

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

Neat idea. Should we worry about how noisy this could end up being for users who have installed Jest globally or are working with a package in a monorepo where node_modules isn't in the workspace root (like Jest)? I think we can build on this and lead users to helpful documentation about how to configure the extension. 👍

Copy link
Member Author

Choose a reason for hiding this comment

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

Probably, especially because users using a global Jest install at the moment also see the "This extension relies on Jest 20+ features…" error message.
It was just that opening VS Code before npm install finished happened to me more often than thinking about global Jest installs.

expect(pathToJest(workspace)).toBe('jest')
})
})

Copy link
Member

Choose a reason for hiding this comment

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

Nice. This makes me sad we duplicated this effort. 😭

Copy link
Member Author

Choose a reason for hiding this comment

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

At least we now can keep the best of both PRs 😉. Sorry that I didn't mention it already when discussing 324.

@stephtr
Copy link
Member Author

stephtr commented May 26, 2018

I will wait for #332 being merged and base my PR on that one (once it is merged).

@stephtr
Copy link
Member Author

stephtr commented Jul 1, 2018

Closing in favor of #340.

@stephtr stephtr closed this Jul 1, 2018
@stephtr stephtr deleted the fix-spawn branch July 1, 2018 15:44
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
3 participants