Stem

@cyco130 the new idea I was mentioning:

```json5
// package.json
{
"dependencies": {
"stem-react": "0.1.0",
// For GraphQL users, instead of `stem-react`:
"stem-react-relay": "0.1.0",
"stem-react-apollo": "0.1.0",

// For Vue users
"stem-vue": "0.1.0",
// Or:
"stem-vue-relay": "0.1.0",

"stem-zustand": "0.1.0",
// Or:
"stem-pinia": "0.1.0",

"stem-tailwind": "0.1.0",
"stem-sentry": "0.1.0",
"stem-telefunc": "0.1.0",
"stem-google-analytics": "0.1.0",
"stem-sitemap": "0.1.0",
// I don't think Prisma would need this, but you get the idea
"stem-prisma": "0.1.0"
}
}
```

```js
// .env
GOOGLE_ANALYTICS=GA-12345
SENTRY=678910
```

Everything is zero-config, there is not even a need to `import 'stem-react'`. It's auto-loaded.

A `stem.config.js` for configuration is optional; the hope is that it's not needed most of the times.

All the user has to do is to write his components, data models, and telefunctions (or GraphQL queries).

Stem plugins can:
- Extend vps
- Extend Rakkas (@cyco130 if you want?)
- Modify the Vite config
- Add middlewares to [HatTip](https://github.com/hattipjs/hattip)
- Add scripts to the client-side
- Wrap the root view component

Stem is only a thin layer of automatic integrations on top of do-one-thing-do-it-well tools that are independent of each other.

Neat thing: there is no proprietary lock-in. It may seem like there is, but it's actually not the case. Let me elaborate.

```js
// node_modules/stem-react/vite-plugin-ssr/_default.page.client.jsx

// The directory `stem-react/vite-plugin-ssr/` implements the integration with vps

export { render }

import React from 'react'
import { hydrateRoot } from 'react-dom/client'
import { PageShell } from './PageShell'

async function render(pageContext) {
const { Page, pageProps } = pageContext
hydrateRoot(
document.getElementById('page-view'),


,
)
}
```

```js
// node_modules/stem-react/rakkas/client.jsx

// The directory `stem-react/rakkas/` implements the integration with Rakkas

// ...
```

This means `stem-react` can include integrations for both vps and rakkas. The only thing that is slightly "proprietary" is the `stem-` namespace (because we'll have the de-facto authority of what these `stem-` packages should or should not include). But anyone is free to introduce a new namespace. Bottom line: [vps's extension mechanism](https://github.com/brillout/vite-plugin-ssr/issues/352) is completly independent of [HatTip's extension mechanism](https://github.com/hattipjs/hattip#middleware-system). This means anyone is free to ship an npm package that extends HatTip while also extending a new vps/Rakkas "competitor".

The no lock-in part is really neat, but it's going to be tricky to explain succinctly and clearly: at first sight, Stem will seem like "yet another monstrous monolith full of lock-in, doom to fail like Meteor". But I've idea for how to communicate that part.

Similarly to to Vite: there are Stem pugins and there are also Stem wrappers.

This means frameworks like [Wind](https://wind-ssg.pages.dev/) can still completely wrap things while using Stem plugins. Alternatively, Wind can use vps without Stem like it does today.

I'm thinking [Vilay](https://vilay.xiniha.dev/en/introduction/) could be a `stem-react-relay` package. (We can still keep its name `vilay` though — I like that name. Just seeing that it now has a logo btw. :grinning:.)

CC @aleclarson @thetre97 @XiNiHa @Sajad-Sharhani

The proposal is centered on package.json, optional stem.config.js, and the plugin entry points described for vps, Rakkas, Vite, and HatTip. Start by reading the linked vps extension mechanism and HatTip middleware system; done would require a concrete, agreed scope and implementation plan, which the issue does not yet provide.

Written by the indexing model from the issue text.