Resolve providers relative to config

[mrmckeb]

Clear and concise description of the problem

We have a monorepo with a shared Vitest config, which defines a provider and coverage reporters.

The current configuration requires us to either install the v8 provider to the monorepo root, or install into each package that uses the shared config.

Ideally, this should be shippable alongside the config (as a dependency).

Suggested solution

I think there are a few options here:

1. Add a "resolveRelativeTo"-type option.
2. Allow passing the provider as an import (provider: import("@vitest/coverage-v8") - where getProvider().name would provide the same info.
3. Automatically try to resolve imports against any extended config paths.

The provider seems to be resolved in a few places:

• vitest/packages/vitest/src/node/cli/cli-api.ts

  Line 69 in b67788c

  !(await ctx.packageInstaller.ensureInstalled(requiredPackages, root, ctx.version))

• vitest/packages/browser/src/node/plugin.ts

  Line 274 in b67788c

  const path = tryResolve('@vitest/coverage-v8', [parentServer.config.root])

• vitest/packages/vitest/src/utils/coverage.ts

  Line 53 in b67788c

  const { default: coverageModule } = await loader.import(builtInModule)

Alternative

No response

Additional context

I'm happy to contribute.

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[hi-ogawa]

Instead of tweaking resolution logic inside Vitest, I feel it's more natural and robust to support fully resolved path as option, something like:

// [my-config-package/index.js]
export default {
  coverage: {
     // this will be resolved to `packages/my-config-package/node_modules/@vitest/coverage-v8/...`
    provider: import.meta.resolve("@vitest/coverage-v8")
  }
}

// [my-config-package/package.json]
{
  name: "my-config-package",
  dependencies: {
    "@vitest/coverage-v8": "..."
  }
}

Have you tried this? I thought this might work already.

[mrmckeb]

You can set "custom" as the value, and pass a module to customProviderModule. That works, but then the reporter options are not passed through, and it seems that it breaks with browser mode from my testing.

So I an alternative would be to fix those two issues - but I wonder if a custom resolution path might be less complex?

[hi-ogawa]

In my opinion, custom provider should cover this use case. Currently browser mode coverage is hard-coded for v8 only and I think there was a issue for that already.

[mrmckeb]

Thank you. Would you like me to take a look at that?

How would options be provided to the customProvider?

[hi-ogawa]

It would be good to know the scope of the issue. I understood the high level motivation is own package for shared config as much as possible. You mentioned reporter options, but I'm not sure what that is. Can you elaborate?

[mrmckeb]

Thanks for taking the time to reply and discuss this. Basically we have a shared config package, where we want to enforce standardised coverage reporting/output, and I'm trying to avoid users needing to install the coverage package into each app in the repo. We could hoist it to the monorepo root as a workaround but it feels like this should be something we can make a dependency, like ESLint plugins can be (now).

The reporter coverage options are these (as an example):

    coverage: {
      enabled: true,
      provider: "v8",
      reporter: ["text", "lcov"],
    },

If I set the provider to "custom", I get the TypeScript error on the reporter:

Object literal may only specify known properties, and 'reporter' does not exist in type '{ provider: "custom"; } & CustomProviderOptions'

The "custom" provider only has a singe option:

customProviderModule: string;