[v3] Automatically inherit common test config in inline projects

[silvenon]

Clear and concise description of the problem

Project configurations can be repetitive, it would be nice for us and for Vitest to have a clear path towards defining what is common and what is specific to that project in one place. Inline projects are a great tool for that, I'm so thankful they made it into Vitest.

However, extending doesn't quite work as I expected, here I expected the project to inherit globals: true:

{
  test: {
    globals: true,
    workspace: [
      {
        test: {
          name: "node",
          environment: "node",
        },
      },
    ],
  },
}

because otherwise any config defined at the root test is a noop when workspace exists, right?

Next I tried setting extends: true on the project to get it to work, but it didn't. I don't really know what it does by default, I suppose it's looking up the directory tree.

What did work was configuring extends: "./vitest.config.ts".

Suggested solution

I would like not having to configure extends on projects, I would like inheritance to just happen. If that makes sense for the direction of v3.

Alternative

Type definitions could be altered in a way that prohibits noop root configs in case workspace is defined, using a discriminated union.

Additional context

No response

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]

This was brought up when discussing #6913, but we didn't do anything special about inline workspace's extends behavior for now. I agree that needing to explicitly add extends feels unintuitive and automatic extends makes sense to me.

I'm not sure why extends: true is not working and not sure if that's intended.

[sheremet-va]

Workspace projects don't inherit the parent config, this is mentioned in the documentation and I prefer that behavior personally to keep things consistent and don't have a distinction between glob projects and inline projects.

extends: true should work and was introduced specifically to make it easier to use inline projects

[hi-ogawa]

I tested extends: true for #7224 (comment), but this might not be copying over Vite level config like plugins, thus failing? https://stackblitz.com/edit/vitest-dev-vitest-z7jkvnhc?file=vitest.config.ts

[silvenon]

The confusing part is that even without extends some plugin hooks like apply and config are being run during testing, this is what led me to believe that the plugins were being applied to the Vitest projects, and why I reported these two issues separately.

A heavy configureServer hook in my personal project also ran, so I had to exclude that plugin via apply even though the plugin wasn't even applied to that project, but I guess to the global Vitest process. Is this something to be concerned about?

[sheremet-va]

Vitest always runs plugins from the root config. config can literally change the root config. Other hooks are running when importing the workspace file, for example, or executing the global setup. I don't see how this is confusing.

https://vitest.dev/guide/workspace.html#configuration

None of the configuration options are inherited from the root-level config file.

// won't inherit any options from this config
// this is the default behaviour

[sheremet-va]

I tested extends: true for #7224 (comment), but this might not be copying over Vite level config like plugins, thus failing? stackblitz.com/edit/vitest-dev-vitest-z7jkvnhc?file=vitest.config.ts

I see why this doesn't work, PR incoming: #7232

[silvenon]

Vitest always runs plugins from the root config. config can literally change the root config. Other hooks are running when importing the workspace file, for example, or executing the global setup. I don't see how this is confusing.

From the standpoint of config being able to modify test configuration it's not confusing (i.e. looking back on this), but from the standpoint of running a project that the plugin isn't being applied to it was misleading to me. This behavior is deeply embeddeed into Vitest, though, so I don't really have suggestions how it could've gone better for me, I just need to get better accustomed to workspaces (which are the bomb, by the way!).

It's great that the fix for extends: true is underway, thank you!

[sheremet-va]

running a project that the plugin isn't being applied to it was misleading to me

You are getting confused here, plugin itself is always applied if the config is resolved. What might not be applied are certain hooks because there were no events that triggered it. For example, it's possible that transform hook is never called by the root project.

The root project is always defined, you cannot disable or remove it. The root project holds all information about the root config and can process files by Vite if there are any custom coverage providers, for example.

The root project also holds the reference to the root Vite server, and configureServer is called by Vite plugin pipeline, not by Vitest.

This is just how Vitest works.

[silvenon]

Seeing that extends: true has been fixed, as far as I'm concerned you can close this ticket.