Support extension settings ('pretest', 'packageManager', 'testCommand', 'extraArguments', and 'executableOptions')

[cafesanu]

Hey @rluvaton. First, thanks for this extension! Truly the only one that worked for us.

Though I would help by adding extension settings.

• The PR adds the possiblity to add settings to change certain behaviours while being backwards compatiple. If user does not add any settings, extention will keep working as before.
• Since the run and watch functions were the same except for the "run" or "watch" string, I merged them into one and now the string "run" or "watch" can be passed to the function.

Extension Settings

Command	Description	Examples	Default
vscode-vitest.preTest	Any command(s) to run before test starts	["npm run script1", "npm run script2" (will run in the given order. If command(s) fail, tests will not run)	[]
vscode-vitest.postTest	Any command(s) to run after test finishes	["npm run clean1", "npm run clean2" (will run in the given order)	[]
vscode-vitest.packageManager	Desired package manager	npm, yarn, pnpm, pnpn dlx, etc	npx
vscode-vitest.testCommand	Define an alternative vitest command	test (e.g. for CRA, package.json test script, or similar abstractions)	vitest
vscode-vitest.extraArguments	Any additional vitest arguments	--silent=true --maxWorkers=2	""
vscode-vitest.executableOptions	Executable option to show	{"debug": false, "run": false} (will only display watch)	{"debug": true,"run": true, "run": true}

Example Settings:

  "vscode-vitest.preTest": ["npm run script1"],
  "vscode-vitest.postTest": ["npm run cleanAfterTest"],
  "vscode-vitest.packageManager": "pnpm",
  "vscode-vitest.testCommand": "test",
  "vscode-vitest.extraArguments": "--silent --maxWorkers=2",
  "vscode-vitest.executableOptions": {
    "debug": false,
    "watch": false
  },

[cafesanu]

Hey @rluvaton. Wondering if you had the chance to see this PR. We would love to use this extension with these changes

[rluvaton]

Hey, sorry, looking now thanks for the contributions

[rluvaton]

the value should not be anything other than run, debug and watch, please change the items type to be enum instead of string

[cafesanu]

Done

[rluvaton]

I think we should the package manager option and instead have that in vscode-vitest.testCommand

so the default value will be npx vitest
and the user can replace to whatever they want to trigger vitest

[rluvaton]

1. having ; would not fail if pretest command fail please replace to &&
2. How other test runner extensions do this, this seems like can be security problem

[cafesanu]

1. Done
2. The way jest runner does it is to simply change the jest command. So, regarding the security issue, I guess it's fine since they also allow you to that whatever and it's a pretty popular extension (1.000.000+ downloads) 🤷

This is what I currently have in mine (I'm using jest runner in the meanwhile while my changes take effect in this repo)

[rluvaton]

If I'm not answering don't hesitate and reach out on Twitter (rluvaton) as I have many notifications

[cafesanu]

I think we should the package manager option and instead have that in vscode-vitest.testCommand

so the default value will be npx vitest and the user can replace to whatever they want to trigger vitest

@rluvaton I initally tried to do this, just like jest test runner does, but this line stopped me from doing it https://github.com/cafesanu/vitest-vs-code-plugin/blob/chore/support-settings/src/run.ts#L84 as it only needs the package manager, so I opted to separate it into two settings so I didn't have to refactor the whole thing

[cafesanu]

@rluvaton Lastly, I added a postTest option as well (3rd commit), as someone in my team needs this option and might be super useful in general

[cafesanu]

@rluvaton sorry to keep bothering. Any chance you can review the requested changes. Would love to have these changes. Thanks!

[rluvaton]

Will get to it today

[rluvaton]

Do you need to use pre and post scripts? I prefer to avoid due to security reasons

[cafesanu]

Do you need to use pre and post scripts? I prefer to avoid due to security reasons

Hey @rluvaton thanks for your review. My argument is that the most popular runner, jest runner, already lets you do this. In our case, we must run translations before we run unit test, and have to clean them after. My whole reason for creating this PR is that we need these steps.

But I totally understand your concern and don't want to force anything here. I would have to fork this extension and create another extension and publish it. Happy to do that if you feel uncomfortable with these changes

[rluvaton]

I'll test it manually tomorrow night and if everything ok I'll merge it, thank you for your patience

[rluvaton]

You had a small bug, fixed it and merging now, thank you!

[rluvaton]

Published!