You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suggest HatTip offers two options for frameworks:
The framework wraps HatTip's CLI, i.e. the user calls $ some-framework dev
The framework user directly uses HatTip's CLI, e.g. $ hattip dev
I've realized that it isn't only about aesthetics, and that's why I'm writing this issue.
The bottom line is that not every user needs HatTip. For example, most vite-plugin-ssr users don't need HatTip.
HatTip is great to get started without having to settle on a deployment strategy. Usually, as they grow, companies settle on a specific deployment provider and don't need HatTip anymore. (In the long term, as HatTip increases its feature set, the percentage of users who stick with HatTip will grow — but it'll take time to get there.)
The advantage of 2. is that users can then simply remove hattip. Whereas with 1. they'll be installing HatTip even though they don't need it.
It isn't a blocker since node_modules bloat isn't that much of a problem, but I do increasingly think that option 2. would be a nice-to-have.
At the end of the day, I think it's the framework authors who should make the decision which way to go, and HatTip could/should support both strategies.
This discussion was converted from issue #57 on November 03, 2024 16:12.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I suggest HatTip offers two options for frameworks:
$ some-framework dev
$ hattip dev
I've realized that it isn't only about aesthetics, and that's why I'm writing this issue.
The bottom line is that not every user needs HatTip. For example, most vite-plugin-ssr users don't need HatTip.
HatTip is great to get started without having to settle on a deployment strategy. Usually, as they grow, companies settle on a specific deployment provider and don't need HatTip anymore. (In the long term, as HatTip increases its feature set, the percentage of users who stick with HatTip will grow — but it'll take time to get there.)
The advantage of
2.
is that users can then simply removehattip
. Whereas with1.
they'll be installing HatTip even though they don't need it.It isn't a blocker since
node_modules
bloat isn't that much of a problem, but I do increasingly think that option2.
would be a nice-to-have.At the end of the day, I think it's the framework authors who should make the decision which way to go, and HatTip could/should support both strategies.
Beta Was this translation helpful? Give feedback.
All reactions