SolidStart Beta 2: Month 2

[ryansolid]

Alright I want to keep updates flowing quicker as we approach RC. So here is the latest.

We took the feedback from #1279 and implemented and released 0.5.0 of SolidStart. Also Solid 1.8.15 solved a number of streaming based issues that had showed up in 1.8.0 as a regression when we introduced the new serializer.

For the most part, it went smoothly but we still had some hiccups on API routes causing them to be merged back in again. We did update them to use radix under the hood instead of the matcher from the router though so some improvements there for maintainability.BasePath has continued to be a bit troublesome. We have landed on using server.baseUrl and a renderAssetUrl from Vinxi. But my understanding is there are still some uncovered cases (nksaraf/vinxi#114). We decided to mostly allow Vinxi to wrap what it needs and us to wrap even further. Supporing event.response now to do most of the things you'd require H3 helpers for. This works better for isomorphic code, as it treeshakes properly.

So now that we've had a few more weeks and slipped in a few more features, including Single Flight Mutations. I want to talk about the remaining things I want to get resolved pre 1.0 RC.

1. vite.config.ts is not actual vite config

It's close but it's not and this is causing a lot of confusion. I'm proposing renaming it to app.config.ts which already works with Vinxi because it is the default. So technically we'd support both but this way all the templates would not scream we are vite. Technically we'd still support Vite plugins and be using Vite for builds, but this would complete our wrapping of APIs and let us expand things further than they are supported today.

Key things being supporting plugins as functions, so that instances could be made for each router (see this issue #1277), and supporting router specific plugins. But mostly remove the expectation that all the vite config options are supported. This is a fairly straightforward step but I want to raise this in case people have alternative suggestions. Perhaps the config format doesn't make sense if we are gutting so much etc...

@lxsmnsyc suggested: #1343 (comment)

2. Vite 5

The PR is already in and we are testing it but it will be another bump of Vinxi. So we will have at least another minor release before 1.0 RC.

3. Granular HMR

This one is new and it already broke some projects the last time we tried releasing it. But I'd like to get this out before a stable version of SolidStart because I think it makes dev experience significantly better. We might need to whether some early bugs but my hope is we can use the beta stage to get there.

---

So I think the plan is to get a 0.6.0 out shortly with these updates. We would love your feedback as always.

[birkskyum]

Sounds great. Regarding the BasePath, this ticket was closed before the solution was validated. I still haven't managed to get nested urls for static sites working (fairly common use case), but when 0.6.0 is released I'll try again with the latest packages and the renderAssetUrl setting (haven't heard of it / tried it before) to see if it does the trick, or if more tweaks are needed. Also, the vinxi serve cli is quite lightly documented so I might use it wrong.

[indeyets]

the main limitation of server.baseUrl approach is that it does not allow to specify full URL (starting with https), so I have no chance to even test it. My patches from the PR work mostly fine, though. at list in my limited testing :)

[ryansolid]

One alternate proposal that @lxsmnsyc suggested to me for app.config.ts was to make the start settings top-level and nest Vite settings:

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

export default defineConfig({
  ssr: false,
  server: {
    preset: "netlify"
  },
  vite: {
    plugins: []
  }
});

We could have the vite options be a function that passes in options like what router they are being initialized for:

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

export default defineConfig({
  ssr: false,
  server: {
    preset: "netlify"
  },
  vite(options) {
    if (options.router === "ssr") ....
    return { plugins: [] }
  }
});

We could also support plugins top-level as a function, and just say we take Vite plugins. Sort of awkward to have multiple ways to do things though.

[indeyets]

both sound fine to me. but there should be proper ts-definitions. preferably with comment-blocks, which describe how various settings work

[birkskyum]

Given how start/vinxi wraps vite/server(nitro), and not the other way around, it does feel more intuitive to have vite settings nested. It's also levels vite and server/nitro which is nice. Potentially they could even both be within a vinxi scope, or in a vinxi.config.ts since all meta-frameworks built on vinxi will need these settings.

[indeyets]

@birkskyum they should be nested and filtered. as we're not allowed to touch some of the settings now, as far as I understand

[birkskyum]

It's interesting how the tanstack router / vinxi examples has an app.config.js and a tsr.config.json, and that's it. Vinxi really does a lot with very little config.

[atilafassina]

I like start as a top-level and vite nested as a function. To me, it resembles closer to what definedConfig is in Vite and thus I think there will be less explanations involved in adopting this.

Same way start as a top-level makes sense because I'd assume apps are more likely to tune start configurations than Vite since Vinxi brings some very good defaults for SolidStart.