hattipjs / hattip Goto Github PK

Windows CI is failing with the message:

Error: Failed to resolve entry for package "@hattip/router". The package may have incorrect main/module/exports specified in its package.json: Failed to resolve entry for package "@hattip/router". The package may have incorrect main/module/exports specified in its package.json.

The package file seems fine and it works in other OSes. Needs investigation.

I'm working on another bun project and I found that you can get more contributors with a website. I built a really simple website and documentation generation tool if you want to add it to your project. Its under the MIT License- I'm just sending it around the bun community so it gains some more traction. If you want to check it out, it's right here. It's all integrated with Github Actions so all you have to do is add the code to GitHub actions and then you're are all set. If you don't want to, just let me know and close this issue- good luck with your project!

Also, just a tip, add a bunch of issues you need help with and label them "good first issue" because then people will see your project from places like goodfirstissues.com.

I was wondering wouldn't it be good if there's some plugin for hattip (i.e: vite-hattip) that handles all the configuration like on rakkas js and we could just focus on creating api with hattip js and deploy anywhere

For example:

// node_modules/some-auth-library/package.json

{
  "name": "some-auth-library",
  "exports": {
    "./hattip": "./dist/hattip.js"
  }
}

// node_modules/some-auth-library/hattip.ts

export default {
  addHattipMiddleware,
}

function addHattipMiddleware() {
  return (ctx) => {
    const response = await ctx.next();
    response.headers.set("Cookie", "auth-secret=...");
    return response;
  }
}

I would even go as far as to have HatTip read all 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.

This is an awesome project! I want to be able to just use various adapters universally under a vite plugin which allows adding backend API to vitejs.
So something like this https://github.com/egoist/vite-plugin-mix but with hattip integration. Happy to make a PR for this!

It would be cool, if we can add support for supabase and appwrite functions. This would allow for a truly hybrid cloud!

Node's native fetch doesn't support setting multiple Set-Cookie headers and it's the only implemented platform that doesn't. Until a native solution arrives it may be possible to support this by monkey-patching Headers.prototype.

We should provide a middleware for automatically handling HEAD requests by stripping the body from GET responses.

We can provide two flavors, one that always handles and one that handles only unhandled ones.

It's a very convenient and widely implemented extension. It should be possible to polyfill in just a few lines of code.

We should implement a multipart/form-data parser.

The problem

Real-world server server-side applications have to have a way of parsing multipart/form-data, including file uploads. The fetch standard provides request.formData but the API is not adequate for server-side use: multipart/form-data is a streaming format but formData is a "random access" one. You're supposed to be able to access uploaded files at any time. That is, you can call formData.get("file1") or formData.get("file2") at any time. This requires buffering the whole request which is prohibitively expensive in many environments.

To add to the inadequacy of the API itself, existing implementations are also lacking:

• Node's native fetch doesn't support multipart/form-data at all (calling request.formData throws).
• Cloudflare Workers' multipart parser treats the file bodies as UTF-8 strings, causing the file contents to be corrupt.

node-fetch does a good job within the limitations of the API by buffering the entire request in memory.

Suggested solution

We can implement a streaming parser for multipart/* as an async iterator (or equivalent interface):

for await (const part of multipartParser(request)) {
  // part.body is a ReadableStream
  // part.headers is a Headers object
  //
  // If the user doesn't drain the stream before
  // requesting the next part, the library will.
  // It is not allowed to save the stream for later
  // use as it would be very inefficient. The user
  // can implement their own buffering though.
}

On top of this, we can implement an easier-to-use interface specifically for multipart/form-data and on a third layer, we can implement file stores for Node FS, Deno FS, Cloudflare Workers KV, AWS S3, etc.

Impact

Such a solution would be very useful for non-HatTip environments too.

TODO

• Investigate how Deno handles this.

Prior art and references

• Busboy
• streamsearch
• Boyer–Moore–Horspool algorithm
• Cloudflare Workers FormData

I want to make my authentication flow easier so that i want to add additional methods to ctx.session like ctx.session.$authorize but after looking the source code for session middleware, i found that the methods on ctx.session are fixed. I think it would be better if the public methods from the custom store are passed to ctx.session 😃

Hattip has a lot of useful tools, but it lacks unit testing support. It sounds good to provide testing utilities like this:

const { fetch, cookies } = createTestClient(hattipHandler);
cookies.set("sessionId", "foobar");
const resp = await fetch("/api/example");
expect(resp.status).toEqual(200)

Prior arts:

• https://github.com/Xunnamius/next-test-api-route-handler : API testing tool for Next.js.
• https://github.com/encode/starlette : Python web framework. It has testClient API for unit testing.

Although the advanced features (CLI, zero config etc.) that we're planning cannot be realistically ported to Deno in the near future, the Deno adapter and the libraries/middleware could be used natively on Deno.

An import map like the following, pointing to the raw GitHub content works OK (save for a few typing issues to be resolved):

{
  "imports": {
    "@hattip/core": "https://raw.githubusercontent.com/hattipjs/hattip/main/packages/base/core/index.d.ts",
    "@hattip/adapter-deno": "https://raw.githubusercontent.com/hattipjs/hattip/main/packages/adapter/adapter-deno/src/index.ts",
    "@hattip/compose": "https://raw.githubusercontent.com/hattipjs/hattip/main/packages/base/compose/src/index.ts",
    "@hattip/router": "https://raw.githubusercontent.com/hattipjs/hattip/main/packages/base/router/src/index.ts",
    "@hattip/response": "https://raw.githubusercontent.com/hattipjs/hattip/main/packages/base/response/src/index.ts"
  }
}

But it would be nicer to have them on deno.land/x. Denoify might help.

I'm not sure how HatTip, vite-plugin-vercel and Rakkas/vite-plugin-ssr would interact with each other.

Opening a ticket for discussing this.

A Vite-based, batteries included zero-config CLI solution would be great for quick onboarding. vavite can already handle most of the heavy lifting so it shouldn't be too hard. Possible features in no particular order:

• Zero-config by default: It should be possible to start or build an application with no config. This requires providing default entry points for all supported platforms.
• Configurable: User should be able to configure anything into any depth. In particular they should be able to:
  • Provide a vite.config.js
  • Set a custom platform-specific entry point
  • Modify bundling options (if bundling is required)
• Static assets: Most deployment targets have special handling for static assets so it should be handled specially by the CLI too. I'm thinking of three modes:
  • No static assets.
  • Static assets served verbatim and not processed by Vite. They either don't require processing or processed via another tool.
  • Static assets processed by Vite (in dev sources are compiled on the fly)

When using the todo template from Rakkas and accessing the dev server, the following error is thrown:

node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

TypeError: Cannot set property crypto of #<Object> which has only a getter
    at Module.install (/node_modules/.pnpm/@[email protected]/node_modules/@hattip/polyfills/dist/crypto.js:7:21)
    at eval (/node_modules/.pnpm/@[email protected]/node_modules/@hattip/adapter-node/dist/index.js:15:30)
    at async instantiateModule (file:///home/parallels/rakkas/node_modules/.pnpm/[email protected]/node_modules/vite/dist/node/chunks/dep-c842e491.js:54236:9)

From my tests, this error only appears with Node.js >= 19. Running the same test with the LTS (18.12.1 as of writing) works properly. It makes sense since Node.js 19 added native support for globalThis.crypto (https://nodejs.org/en/blog/announcements/v19-release-announce/#stable-webcrypto)

Node: 19.0.1
PNPM: 7.14.0
OS: Ubuntu 20.04

Hello! This is an issue to track the support of Lagon with HatTip. I've created an issue in Lagon's repo too:

• lagonapp/lagon#187

It should already work out-of-the-box, but it's a good idea to keep a reference.

Node 18 CI is hanging at the start of the Deno server launch. Needs investigation.