-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use universal-middleware
#16
base: main
Are you sure you want to change the base?
Conversation
Hi. I stumbled across this extension while trying to figure out the best way to deploy to Node and it looks awesome. The one issue I have is that I am using Auth.js for authentication and was previously using universal middleware to add the logged in user to the context. When I use the vike-node extension though, my modified context is not being seen by Vike so I assume it's using a different context. I'm assuming these draft changes will mean my context changes will be seen by Vike via the use of universal middleware...is that right? Not sure how far away these changes are, but is there another way that I can add the user to the context using regular middleware so that Vike will see that when I am using vike-node? |
@jasonhilldm I would suggest to wait for this PR to be finished, as it will fix your issue. import { getContext } from "@universal-middleware/hono";
app.use(
vike({
pageContext: (req) => getContext(req)
})
) |
Thank you - that worked perfectly. |
BREAKING CHANGE: cache related options have been removed
BREAKING CHANGE: `getPageContext` has been removed in favor of universal-middleware context. See [Updating the Context](https://universal-middleware.dev/recipes/context-middleware)
05aa8d6
to
775df55
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started reviewing a bit, I'll resume tomorrow.
Express: | ||
[See complete list of supported servers](https://universal-middleware.dev/reference/supported-adapters) | ||
|
||
#### Express: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The example needs to be updated to use vike-node/express
.
``` | ||
### Codebase without `vike-node` | ||
```diff | ||
// server/index.js | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here: example bellow uses vike-node/connect
.
const port = +(process.env.PORT || 3000) | ||
app.listen(port, () => console.log(`Server running at http://localhost:${port}`)) | ||
} | ||
``` | ||
## Migration guide: | ||
### `0.1.x` to `0.2.x` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use CHANGELOG.md
instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like a couple of BREAKING CHANGE:
are missing. I guess we'll squash merge so we can just push empty commits to append any missing BREAKING CHANGE:
.
"browser": "./dist/runtime/handler-web-only.js", | ||
"default": "./dist/runtime/handler-web-and-node.js", | ||
"types": "./dist/runtime/handler-web-only.d.ts" | ||
"./handler": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should remove this export; I wonder why the user would want to import Vike's handler which, it itself, is fairly boring (the compression is nice but vike-node
's main benefit is Vite server transpilation + HMR + standalone build).
@@ -0,0 +1,10 @@ | |||
import { Get, UniversalHandler, pipe } from '@universal-middleware/core' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious: does the file name extension .handler
have a functionality or is it just a convention?
const compressMiddleware = compressMiddlewareFactory()(request) | ||
|
||
return async (response) => { | ||
if (!globalStore.isPluginLoaded && nodeReq) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why && nodeReq
? We don't want to compress for CF but it still seems too restrictive 👀
headers, | ||
platformRequest, | ||
options | ||
export const renderPageCompress = ((options?) => async (request, _context, runtime: any) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Style: it seems to be agnostic to renderPage so I'd call it differently e.g. compressMiddleware
.
staticConfig = resolveStaticConfig(options?.static) | ||
} | ||
|
||
if (globalStore.isPluginLoaded) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Style: I'd rename globalStore.isPluginLoaded
to globalStore.isDev
. It's more explicit and, at the end of the day, that's the info we're looking for and testing against.
async function serveStaticFiles(req: IncomingMessage, res: ServerResponse): Promise<boolean> { | ||
if (!staticMiddleware) { | ||
const { default: sirv } = await import('sirv') | ||
staticMiddleware = sirv((staticConfig as { root: string; cache: boolean }).root, { etag: true }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In itself I like the idea to have a built-in static server. Just not sure this is the right place. But let's keep it since it was already here before this PR.
In the long term (after this PR), what could be lovely is to leverage the upcoming partial eject functionality: upon running $ eject vike-hono entry
the Hono entry is ejected, giving the user the opportunity to switch out the static server. In other words, the user can use a Hono server without writing a single line of server code. The idea here is that vike-hono
, vike-telefunc
, vike-auth
, ... would all automatically integrate with each other. To swap the server all the user needs to do is to install vike-express
instead of vike-hono
(assuming he didn't write/eject any server code) and everything would work equally.
@@ -27,7 +27,8 @@ | |||
}, | |||
"pnpm": { | |||
"overrides": { | |||
"vike-node": "link:./packages/vike-node/" | |||
"vike-node": "link:./packages/vike-node/", | |||
"esbuild": "^0.24.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we can remove this line?
Notable changes
@universal-middleware/compress
for compressiongetPageContext
hook is removed. The wholecontext
from universal middlewares is given as a Context torenderPage
. This means that the same effect can be achieved by any custom universal middleware.Next steps (not in this PR)