Possible to use relative paths for outputFormatters names?

I’m working on using cli2 in a CI/CD Pipeline (specifically Azure DevOps Pipelines). A tl;dr is that this would be slightly easier if the name for the formatter I’m using (junit specifically, but all of them that write a file seem to use the name value in the same way) would accept/understand an absolute path rather than always treat it as a relative path. I’m not sure offhand how difficult it would be to implement that, so it’s not a deal-breaker if it’s not possible/too difficult/introduces too much complexity.

A longer explanation: Azure DevOps (and many other CI CD tools) have system variables that represent the places where stuff goes. This makes your pipeline more dynamic, and prevents you from relying on assumptions about file system layouts (layouts that could change at some point). As an example, Azure DevOps checks out the repository to something like /home/vsts/work/1/s. This is also the working directory that scripts execute from. There is a separate directory for test directory, something like /home/vsts/work/TestResults, represented by the variable Common.TestResultsDirectory. If I want to put my test results there, I have to specify a name value of something like ../TestResults/Test-$(Build.SourceVersion).xml. Then later on when I ingest the test results I can specify a path of $(Common.TestResultsDirectory)/Test-$(Build.SourceVersion).xml. But this only works if the assumption continues to be true that TestResults is a folder that exists in the same directory as the working directory. If I try to specify a name of $(Common.TestResultsDirectory)/Test-$(Build.SourceVersion).xml in my config file, the formatter treats it as “relative” rather than absolute. The actual string value ends up being something like /home/vsts/work/1/TestResults/Test-99aa992c60de7d7e44d77e7c4d84359174b61d65.xml but the formatter looks in /home/vsts/work/1/s/home/vsts/work/1/TestResults/Test-99aa992c60de7d7e44d77e7c4d84359174b61d65.xml.

[DavidAnson]

Specifically, I’m thinking of another test directory like this: https://github.com/DavidAnson/markdownlint-cli2/tree/main/test/outputFormatters-params

Except use a JS file for config and populate the name parameter with something like path.resolve(__dirname, "custom.xml"). It may be necessary to further tweak that for Windows.

You’ll use npm run update-snapshots to update the tests after adding an entry to the JS test file (don’t forget to delete the output files as in the example I use).

[DavidAnson]

The workflow is a little bit weird because of how snapshots behave. You can update them at any time, so it’s not that you are locked into the initial behavior, but yes, I did something like what you describe where I reverted your change to make sure that the test and snapshot would have failed without it.