Plugin system for added functionality.

[urkle]

Clear and concise description of the problem

In my projects where I am using jest I utilize several "plugins" to add functionality to Jest (note they are not really plugins as jest also lacks a plugin infrastructure).

Specifically the ones I am using are from this repo https://github.com/negativetwelve/jest-plugins

What would be "nice" would be to have a way to

1. register additional possible globals
2. some nice way to be able to import them from 'vitest' (I do not believe this is even possible).

Suggested solution

unknown

Alternative

No response

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.

[sheremet-va]

As far as I'm concerned, these are simple functions that run after jest sets up environment.
Why can't you do this in setupFiles config option for Vitest?
We are not against some plugin interface (is in discussion inside a team), but your usecase is quite simple.
You can already define global variables with define option in config (or manually in setupFiles), and I don't see a point in importing it from Vite.

[urkle]

I have setup something like that (deriving off of the jest-plugins but doing it all ES modules).

I have it mostly working .. Except it would be nice to be able to query the current configuration from vitest. e.g. my current use is to query if "globals" is enabled or not.

Also I meant "import from vitest" not "vite" (been writing that wrong all day today)

For what I have "working now" ( https://github.com/OutOfOrder/vitest-plugins )

[urkle]

@sheremet-va so close.. Please see #843

[urkle]

I think for #843 is where having a plugin interface would make this much simpler and easier. e.g. have a config options for plugins: [] and have vitest load the modules and call an setup method in the module and pass the vitest module as an argument.. Then it'd be able to access the exports easily in the right context.

[sheremet-va]

I think for #843 is where having a plugin interface would make this much simpler and easier. e.g. have a config options for plugins: [] and have vitest load the modules and call an setup method in the module and pass the vitest module as an argument.. Then it'd be able to access the exports easily in the right context.

Yes, we had the idea of creating a config option, like addons that receives array of filenames that export default a function. But the team haven't disscussed it yet, since we don't really know what to expose.

[urkle]

@sheremet-va yeah.. Something simple like having the function take one argument could work well.

// the exported function from the library
export default (vitest) => {
    // make calls to vitest.? to register things. e.g. a vitest.addons.registerExports(exports)
   vitest.addons.registerExports({context: vitest.describe});  // or just have them assign directly to vitest.addons ?
}

// in test code. if globals: true
context(() => {
   // do tests
});
// in test code. if globals: false
   import { addons } from 'vitest';
   const { set, context } = addons.methods;

context(() => {
   // do test
});

Then I wouldn't have to include vitest in my plugins at all and could completely drop the vitest-plugins package and just do a addons = ['vitest-plugin-set', 'vitest-plugin-context'] in the vitest config.

If you give me some direction I can build up a PR proposal to the team.

[patak-dev]

It may be a good idea to wait a bit. There were some discussions about implementing a feature similar to playwright fixtures (https://playwright.dev/docs/api/class-fixtures). It will let you extend the test context, and each test will receive it instead of the current done callback (that can be replaced by a standard new Promise call). I dont know if it could cover your use case, but the resolved config coild be passed as part of the context.

[sheremet-va]

Extending tests is implemented with Test Context. Nothing is stopping anyone from creating "plugin-like" packages that jest has. Please, note that if you are importing directly from Vitest, your library should be inlined with deps.inline.