-
-
Notifications
You must be signed in to change notification settings - Fork 16
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
Zero-config library integrations #18
Comments
This idea is kind of growing on me. Do you know anyone else doing this? |
I don't think anyone else does this, and I think we should do it :-). |
A user today on Discord:
Speaks volume of how much library zero-config integration is being craved for. |
@elderapo Curious: why the downvote? |
@brillout, a few things:
import { authMiddleware, loggerMiddleware } from '@elderapo/hattip-middlewares';
if (!process.env.DISABLE_AUTH) {
app.use(authMiddleware());
}
if (!process.env.DISABLE_LOGGER) {
app.use(loggerMiddleware());
}
import { loggerMiddleware } from '@elderapo/hattip-middlewares';
app.use(loggerMiddleware({ level: "debug })); |
// hattip.config.js
import { auth } from 'awesome-auth/hattip'
import { logger } from 'awesome-logger/hattip'
// HaTip loads `hattip.config.js` before it auto-loads npm packages. It sees that `auth()` and `logger()` are
// already installed and therefore skips auto-loading them.
export default {
plugins: [
auth({ strategy: 'one_time_password' }),
logger({ disable: process.env.DISABLE_LOGGER })
]
} I believe this addresses all your concern. Thing is, it becomes cumbersome to have to add your tool's plugins to Vite, HatTip and potentially more tools. |
I don't see how that is any better than normally applying middlewares. What is wrong with the following code that needs fixing: // handler.ts
import { compose } from "@hattip/compose";
import { auth } from 'awesome-auth/hattip'
import { logger } from 'awesome-logger/hattip'
export const handler = compose(
authMiddleware({ strategy: 'one_time_password' }),
logger({ disable: process.env.DISABLE_LOGGER }),
...
); |
If it were only about adding one plugin to HatTip, then I'd agree. But it starts to become annoying when installing one tool means to 1. add a plugin to HatTip, 2. add a plugin to Vite, etc. Reducing the installation step to a single step |
Hmm... why would custom
I am not sure this is such a big deal tbh... |
Telefunc and vite-plugin-ssr: both need integration with Vite as well as with HatTip. |
Closing for now. I'll re-open it in the future when the need for this arises. |
Now relevant for #51. Basically: // node_modules/vite-plugin-ssr/package.json
{
name: "vite-plugin-ssr",
exports: {
"./hattip-auto-integration": "./dist/entry-hattip.js"
}
} // node_modules/vite-plugin-ssr/dist/entry-hattip.js
export default handler;
import { renderPage } from 'vite-plugin-ssr/server'
async function handler(ctx) {
const pageContextInit = { urlOriginal: ctx.request.url }
const pageContext = await renderPage(pageContextInit)
const { body, statusCode, contentType } = pageContext.httpResponse
return new Response(body, {
status: statusCode,
headers: {
"Content-Type": contentType
}
})
} This means HatTip seamlessly integrates with the meta framework. No To support meta frameworks that don't have a |
For example:
I would even go as far as to have HatTip read the
pacakge.json#exports
of all dependencies to see if they contain a HatTip zero-config integration.So that all the user has to do is to
npm install some-auth-library
. Zero integration code needed. Works across all JS server platforms.The text was updated successfully, but these errors were encountered: