Adoption of RunnerConfig with outputDir derived from PersistConfig #227

Activity

1. BioPhoton

   self-assigned this

   on Nov 10, 2023
2. BioPhoton

   added

   🧩 cli

   on Nov 10, 2023
3. BioPhoton

   added this to the 2. Integration milestone on Nov 10, 2023
4. BioPhoton

   added

   🤓 UXUX improvement for CLI usersUX improvement for CLI users

   🔬 testingwriting testswriting tests

   on Nov 10, 2023
5. BioPhoton commented on Nov 10, 2023

   

   BioPhoton

   on Nov 10, 2023

   CollaboratorAuthor

   More actions

   @matejchalk how would you implement this without confusing code or user :)
   Let me know you thought, I started and realised it is not trivial :D
6. matejchalk commented on Nov 11, 2023

   

   matejchalk

   on Nov 11, 2023

   Collaborator

   More actions

   how would you implement this without confusing code or user :)
   Let me know you thought, I started and realised it is not trivial :D

   I'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 runner function 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?
7. BioPhoton commented on Nov 12, 2023

   

   BioPhoton

   on Nov 12, 2023

   CollaboratorAuthor

   More actions

   Love it! Will close the part and link this in #92
8. BioPhoton

   closed this as completedon Nov 12, 2023