You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
There is a class of projects that do not play nice with Stryker's way of mutating files inside the sandbox (a subdirectory inside .stryker-tmp). We can spend a lot of time debugging the issues, going through the test runner issue tracker to create an issue, creating PR's/making noise to please fix our use case. Or we can allow files to be mutated in place.
I would like to allow Stryker to mutate files "in-place". Meaning to not create a sandbox, but instead mutating the actual input files. I want mutation switching (#1514) to be implemented first, that way we can keep using parallel processes (since all mutants are in the code, we don't need to write every mutant to disk one by one).
We should be careful to warn users of the consequences. Some thoughts:
Enable this new functionality with a new cli flag --inPlace, or using a config file "inPlace": true, default is false.
When enabled, make a copy of the source code in a temp dir. Preferably in the os's temp dir instead of the current working directory.
After instrumentation, copy the instrumented files to the current working directory, instead of the sandbox file.
Set back the file's original content after Stryker is done.
Use a node exit hook to really make sure we allow us to set original files back.
Describe alternatives you've considered
What we've been doing until now is saying to everyone to fix the issue for us.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
There is a class of projects that do not play nice with Stryker's way of mutating files inside the sandbox (a subdirectory inside
.stryker-tmp
). We can spend a lot of time debugging the issues, going through the test runner issue tracker to create an issue, creating PR's/making noise to please fix our use case. Or we can allow files to be mutated in place.List of issues that might be helped by such an option:
#2147
#1564
#717
#1957
#2185
#2274
Describe the solution you'd like
I would like to allow Stryker to mutate files "in-place". Meaning to not create a sandbox, but instead mutating the actual input files. I want mutation switching (#1514) to be implemented first, that way we can keep using parallel processes (since all mutants are in the code, we don't need to write every mutant to disk one by one).
We should be careful to warn users of the consequences. Some thoughts:
--inPlace
, or using a config file"inPlace": true
, default isfalse
.Describe alternatives you've considered
What we've been doing until now is saying to everyone to fix the issue for us.
The text was updated successfully, but these errors were encountered: