[Bug?]: Plugins prop can be a function but types don't show that

[edivados]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

Expected behavior 🤔

Steps to reproduce 🕹

Steps:

import { defineConfig } from "@solidjs/start/config";

export default defineConfig({
  plugins() {
    return []
  }
});

Context 🔦

No response

Your environment 🌎

@solidjs/start: 0.4.10

[ryansolid]

Does Vite support plugin functions.. I was trying to avoid straying from Vite conventions in Vite config. It might be not accomplishable but generally that was the goal.

And I now see #1277 is why you reported this. Hmm...

[edivados]

And I now see #1277 is why you reported this. Hmm...

Not quite. It helps with that but I reported this one because Solid-Start accepts a function for plugins but doesn't show it. Why hide it?

[nksaraf]

Vite's way of supporting something like this is to make the whole config a function that can be run multiple times. But I think that's overkill and just making plugins be a function solves all the issues

[ryansolid]

@nksaraf Yeah I just worry that people won't expect that. People expecting Vitest to work with the same config. I'd rather just wrap the whole thing in a function if that is the case. I'm ok with us diverging from Vite config in the sense that not all options are present or work. Because then people will not use them. But we can't change the API of existing options I think and still gain the right benefit. If the whole defineConfig accepts a function and that would work in Vite and Vitest I'm pretty stoked.

I don't know enough about the testing story (maybe @atk does) to quite understand it. And maybe stuff like the way insert plugins will never make it work so my point is mute. But my hunch is that building to the future it is a safer stance to take.

[nksaraf]

While I agree if we could just accept a list of plugins and have them work everywhere I would do that. The functional syntax is important for each router to have an independent pipeline (I know u already know that). We could make the whole config a function and then call that twice to get two copies of the config (one for server and client) this might be the best idea for this stance right now.

• For testing. What Vinxi is going to do is .. you can import from the app.config.js or vite.config.js and the app instance Vinxi creates will have a function called 'getTestConfig()' that will adapt the internal vite config to a vitest config