feat(#390): Add in json-summary reporter missing error message

[CollinHerber]

Resolves: #390

I'm having some trouble running this locally atm. This code is untested and is theoretical and does not currently contain test but wanted to get something out there to prompt discussion.

I have reached out via email for more information on local dev. May be worth it to provide a CONTRIBUTING.md file for those wanting to contribute and provide information on doing so.

[davelosert]

Hi @CollinHerber ,

first of all Thank you for this PR.

I also saw your mail, but I am a bit swamped right now.

I admit that this repository currently lacks some contribution guidelines and docs as well as automated testing. I'l see if I can get something in place next week.

[davelosert]

I am pretty certain that this won't work, as the vitestConfig is usually not a .json File, but mostly is a .ts or .js file and can have various formats. So we either need to take the simple approach and handle this file as a string, looking for the reporters configuration through string extraction (or regexp) - or see if vite has some API to handle the parsing of this configuration.

For the latter, I found https://vitejs.dev/guide/api-javascript.html#loadconfigfromfile - but I am not sure if this is usable or will reliably work, given that it might even have to compile a .ts file... but it could be worth a shot.

[davelosert]

@CollinHerber : So I just merged several contribution-improvements where I fixed the tests and also added biome.js as linter+formatter for easier folloing the coding guidelines.

I also took the chance and tested if I couldn't use the loadConfigFromFile function from vite and actually made that work like that:

import { loadConfigFromFile, type UserConfig } from 'vite';

async function readViteConfig(configPath: string): Promise<UserConfig | undefined> {
  const result = await loadConfigFromFile({
    command: 'build',
    mode: 'production',
  }, configPath);

  return result?.config;
}

export {
  readViteConfig
};

The only drawback of this approach is that vite woulds suddenly become a dependency, or at least peerDependency, of this project, and I am not sure yet what to think of that.

I guess having it as strict dependency would have the advantage of it being bundled into the action in itself and, as such, be more stable. Given that the congfiguration of vite is quite stable, this shouldn't be too much of an issue - but it could mean some troubles in the future.

As such, I'd say if we do this, we still keep the string parsing as a backup in case the vite way fails.

As there are many unknowns to this feature, let me know if you are still interested in trying to implement this yourself or if you want me to take things over (with which I'd be totally fine).

[CollinHerber]

@CollinHerber : So I just merged several contribution-improvements where I fixed the tests and also added biome.js as linter+formatter for easier folloing the coding guidelines.

I also took the chance and tested if I couldn't use the loadConfigFromFile function from vite and actually made that work like that:

import { loadConfigFromFile, type UserConfig } from 'vite';

async function readViteConfig(configPath: string): Promise<UserConfig | undefined> {
  const result = await loadConfigFromFile({
    command: 'build',
    mode: 'production',
  }, configPath);

  return result?.config;
}

export {
  readViteConfig
};

The only drawback of this approach is that vite woulds suddenly become a dependency, or at least peerDependency, of this project, and I am not sure yet what to think of that.

I guess having it as strict dependency would have the advantage of it being bundled into the action in itself and, as such, be more stable. Given that the congfiguration of vite is quite stable, this shouldn't be too much of an issue - but it could mean some troubles in the future.

As such, I'd say if we do this, we still keep the string parsing as a backup in case the vite way fails.

As there are many unknowns to this feature, let me know if you are still interested in trying to implement this yourself or if you want me to take things over (with which I'd be totally fine).

Apologies for the lack of responses, been a bit of a wild week and change for me at my career. I've been spearheading a new company initiative and don't have the luxury of working on many "It would be nice to have"s atm.

It may be best for you to take over, but ofc feel free to use anything I've made.

On the vite dependency thing; I personally think that's a great idea. Their loadConfigFromFile will almost certainly continue to be maintained and provide a maintenance-free approach.

[davelosert]

Alright no worries, I'll take over then. 🙂

Again, thank you very much for this PR and the work you've put into this, it will certainly help.

Wishing you al the best on your new career opportunity!