-
-
Notifications
You must be signed in to change notification settings - Fork 19
Description
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.