-
-
Notifications
You must be signed in to change notification settings - Fork 13
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
bundle adapters in hattip
to ease adoption
#56
Comments
hattip
hattip
to ease adoption
Hi we're working on a Vite based CLI that will bring a very convenient DX. It's only semi-functional right now but when it's ready in a few days, it will feel like using one of Vite-based metaframeworks like SvelteKit, Rakkas, or Astro, minus the frameworK. There will also be a project initializer ( I'll close this when we release the CLI. |
The CLI won't address the outlined problems :) If the CLI is yet another package on NPM, the downloads will be split among yet another npm package. You can bundle everything hattip related in one npm package to incentivise people to adopt hattip due to higher downloads on NPM. Thinking out loud here on how to drive adoption for hattip |
We've plans to significantly increase the number of HatTip users. I think the number of npm downloads won't be an issue then. |
Yes, but the |
We are interested. Running into multiple issues with express right now. Our architecture is unusual. One server runs everything. Modules export handlers that are imported by the server. So kinda a monolith but not really. Most things are split by module. Large downside:
|
Vite handles linked npm packages as |
Problem
hattip
dependencies slightly lowering DX but, more importantly, spreading the downloads of Hattip across multiple packages.Sugesstion
Bundle all adapters in
hattip
likehattip/adapter/node
.We had a similar discussion for inlang opral/monorepo#460 (comment)
The text was updated successfully, but these errors were encountered: