[RFC] Fullstack Primitives

[atilafassina]

We've been taking a close eye on the issues and questions you have asked when creating apps with SolidStart, questions about recommended patterns and ecosystem. While we very much do not want to expand the scope of @solidjs/start , we understand there are things that every app needs which our core package does not cover.

With DeVinxi merging into new main, we have a unique opportunity to simplify our monorepo architecture in a single round. This would lift a big burden on maintaining releases and the code by reducing the amount of contributions only to things relevant to the meta-framework. So we're considering bringing a new set of packages we're calling Fullstack Primitives.

No more templates

We are removing the /examples directory from our monorepo. They have a new home at solidjs/templates, and if you wish to create an official template - that's the recommended space now.

It's worth pointing out that unfortunately our team is small and maintaining a diverse range of templates and integrations has proven to be extremely time consuming. So there is an open issue for supporting community templates in a way that does not require a centralized repository, so I'd recommend more specific templates to be created in their own repositories. So if you have intention to create an integration template, I'd recommend adding support on that issue so we can prioritize it accordingly to necessity.

New repository architecture

.
├── .changeset
├── .github
├── .vscode
├── apps/
│   ├── tests
│   │ ├── end-to-end
│   │ └──fixtures/
│   │     ├── bare
│   │     ├── basic
│   │     ├── experiments
│   │     ├── hackernews
│   │     └── todomvc
│   └── landing-page
└── packages/
  ├── start
  └── primitives
	  ├── image
	  ├── csp
	  ├── security
	  ├── og
	  ├── seo
	  ├── ai
	  └── ...

1. Removing fixtures and archived examples.
2. Create a satellite ecosystem of "primitives"

Not frameworks, primitives

The motivation behind SolidStart has always been one to provide the right set of primitives so you build the solutions. You can set apart and put it together the way it fits your usecase. And that flexibility comes with a price to avoid some abstractions.

Things like an <Image /> optimization component, or an OpenGraph image generation. Security headers and Content Security Policies. All these (and others) are examples that the vast majority of apps will need but that carry opinions which shouldn't be part of the core package.

Packages that we are already working on and from today on will have issues to have their progress tracked.

• image -> <Image /> component
• csp -> helpers to create valid Content Security Policies
• seo -> sitemap.xml and robots.txt routes
• ai -> AGENTS.md and/or rules to be added to help speed-up SolidStart project
• security -> other security related improvements (headers, CSRF protection, etc)
• primitive-template -> a boilerplate to help you create your own primitives

Contributing

A Pull Request removing rearranging the architecture is already up. The next step will be to convert the main branch into the target for DeVinxi and move the current 1.0.0 package into a 1.x branch so we can release and maintain it from there.

The new primitives work will target only SolidStart 2.0.0. And if you want to propose a primitive or work on some of the ones we have in our roadmap, check the issues for the primitives label. Please, do not create pull request without first discussing it on an issue as there is a lot of considerations to be had towards our internal roadmap and architecture changes for SolidStart 2.0.0.

---

As always, we appreciate the feedback and are open to discussions.

Cheers,
Start Team 🧉

[doeixd]

Hello! I really like the direction this is heading. Moving templates into their own home feels like a smart call. there were always so many PRs around them in the main repo, so this separation should help a lot.

The idea of “primitives” is exciting 👍. It immediately reminded me of Nuxt Modules, Nuxt Fullstack Templates, and Nuxt Layers.

One thing I’m curious about: the current Vinxi implementation is already very extensible, with lots of hooks into different parts of the metaframework. Would something similar be needed here to allow developers to build their own primitives, perhaps in a way comparable to how Nuxt Layers/Modules work?

If so, would contribution in this area be welcome?

[atilafassina]

With the new architecture, we're moving the node.js runtime (Nitro, at the moment) into its own separate plugin. This means the wiring will be "exposed" to the end-user.

Ultimately, what this means is that you'll be able to author Vite-Plugins, Nitro plugins, or even bring your own backend runtime. Maybe I'm getting ahead of myself by now, but that's what it will look like towards the 2.0.0-beta. If that sees that much traction and we arrive at a place we can even build on top of it (to evolve into something as polished as Nuxt Modules), we might just do that.

Contributions are always welcomed, I'll merge the new Contribution docs ASAP and following those steps we can totally land into something. As of right now, we're in this unique transition phase, so I wouldn't recommend jumping straight ahead and starting to code, there are still a few moving pieces that need settling...