-
Notifications
You must be signed in to change notification settings - Fork 294
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
Conversation
Pull Request Test Coverage Report for Build 389
💛 - Coveralls |
I updated |
I hate to be asking it at this point in your PR but can you explain why we need another |
No problem. You actually introduced the second occurence with Jest#5658 😉. The issue is that if we would like to omit the Since Runner and Settings are independent from each other, a cleaner solution than supplying |
Sweet, thanks for those links and details. Since they're all using |
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.
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) |
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.
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.
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.
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": "" |
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.
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 }) | |||
|
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.
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' })
}
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.
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 |
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.
This would remove the check for jest.cmd
and fail on Windows systems.
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.
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' |
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.
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. 👍
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.
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') | ||
}) | ||
}) | ||
|
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.
Nice. This makes me sad we duplicated this effort. 😭
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.
At least we now can keep the best of both PRs 😉. Sorry that I didn't mention it already when discussing 324.
I will wait for #332 being merged and base my PR on that one (once it is merged). |
Closing in favor of #340. |
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