Add configuration option for custom Pester module path

[johlju]

@JustinGrote this is my attempt to fix issue #108. Please give pointers if I missed something, I followed how runTestsInNewProcess was done to get an idea where to change stuff. 🙂

• Add new configuration property pesterModulePath
• Update CONTRIBUTING.md to help contributors.

Fixes #108
Closes #95

[johlju]

I can build the project locally with npm run build v12.0.0 and then I get a .vsix file, but VS Code says it is not compatible with my version of VS Code (1.65.2). Any tips what I do wrong?

[JustinGrote]

I can build the project locally with npm run build v12.0.0 and then I get a .vsix file, but VS Code says it is not compatible with my version of VS Code (1.65.2). Any tips what I do wrong?

The latest "main" branch requires Insiders, because the next version of VS Code runs NodeJS 16 and has some breaking changes I had to fix.

[johlju]

The latest "main" branch requires Insiders, because the next version of VS Code runs NodeJS 16 and has some breaking changes I had to fix.

Now I got that "streams" error you talked about so have to wait to practically test this change when that is resolved.

[JustinGrote]

The latest "main" branch requires Insiders, because the next version of VS Code runs NodeJS 16 and has some breaking changes I had to fix.

Now I got that "streams" error you talked about so have to wait to practically test this change when that is resolved.

Main shouldn't have any streams errors, it should test fine. There should be a option to "run extension" in the debug window that will start a new vscode instance running the current version of the extension.

[JustinGrote]

Also all of the aspects you listed in Contributions are covered by the tasks and debug configs

[johlju]

Also all of the aspects you listed in Contributions are covered by the tasks and debug configs

Ah. That is the way you suppose to do it. 🙂 I document that too. I thought I would document stuff that I was looking for, to help others in the future. 🙂

[johlju]

@JustinGrote the debug experience was awesome! Pretty neat how seamless it was. It now works perfectly for both single project workspace and a multi-project workspace. Just need to fix the TODO (loop through workspaces) and the documentation, then I feel pretty great about this change. Do you see anything that could be improved in the code (both style and logic)?

[JustinGrote]

I'll try to find some time to review tonight, thanks for the contribution!

[johlju]

@JustinGrote I moved doc changes to another PR. Ready for review now.

[johlju]

Here is a run with this change. I do not have any Pester module installed in any $env:PSModulePath.

PS> Get-module Pester -ListAvailable
PS>

It uses the relative path .\output\RequiredModules\Pester to find the Pester module.

Test run in SqlServerDsc:

Note: Those with the yellow symbol that are left are not yet converted, the scripts have a return-statement at the top to not run Pester 4 tests

[JustinGrote]

Thank you so much for your contribution! I'll try to review again sometime this weekend and hopefully we can get this merged.

[JustinGrote]

FYI a vsix is automatically built on every commit, you can access it here to start using it right away:
https://github.com/pester/vscode-adapter/actions/runs/2039455419#artifacts

[JustinGrote]

LGTM After Changes

[JustinGrote]

@johlju thanks for your contribution! I'll push a new release after a couple other items I want to get completed.