Repository navigation
Adoption of RunnerConfig with outputDir derived from PersistConfig #227
Description
Activity
@matejchalk how would you implement this without confusing code or user :)
Let me know you thought, I started and realised it is not trivial :Dhow would you implement this without confusing code or user :)
Let me know you thought, I started and realised it is not trivial :DI'm not sure I understand the motivation (it's been a while, so maybe I don't remember) 😕
The runner output is specified by the plugin author, is only intermediate and also there's in general more than one and each can use a different location (multiple plugins, potentially different authors). While the output directory is specified by the end-user (quite likely not the same person as plugin author) and is intended to be read (markdown) or used (json for upload) afterwards.
I don't really see those locations as logically linked in most situations. And I think it would be confusing to resolve relative paths in different ways. I think the relative paths should either all stay relative CWD, or should be relative to the config file which specified them (but then we would have to differentiate paths specified with CLI arg, because there you'd expect CWD - yeah, probably that's also confusing).
For the locations we have, I see them being used like this:
config- usually in root, sometimes in project dir for cross-team/multi-product monorepos
- included in version control
- written (perhaps initially generated) and maintained by user
- typical example:
./code-pushup.config.ts
persist.outputDir- relevant to user, will check those outputs at least first time
- not included in version control
- typical example:
.code-pushup/report.json,.code-pushup/report.md(.code-pushup/added to.gitignore)
plugins[].runner.outputFile- not in version control
- not interesting for user (very raw)
- once
runnerfunction supported (Enhance DX of plugin authors #92), probably not relevant for small custom plugins either - relevant to plugin authors who want to distribute their plugin as an NPM package
- typical example:
node_modules/.code-pushup/eslint/runner-output.json
I see all those purposes as fairly independent, so resolving them relative to each other would probably only cause confusion and complicate things.
Am I missing something?
This will make it easier to work with different cwd and config location settings.
npx ../../dist/packages/cli collect --config=../../packages/cli/test/plugin-progress-bar.config.mock.ts --outputDir=../../tmprelated to #92