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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: