Make vt easier to install and setup

[stevekrouse]

In a recent vt demo, I saw a number of frictions in installing and setting it up:

1. The first (meta) issue was not knowing it exists. The user clearly wanted it to exist, but just assumed it didn't. I don't know how to solve this problem.
2. The next issue was that the user had to install Deno, but the user was a Python person who had never heard of Deno, and that was confusing and random to them.
   a. Can we avoid having Deno as a dep somehow?
   b. Clicking out to the Deno install page wasn't ideal. Should we include a recommended Deno install command in our REAMDE? If we need to have a more interactive page that lets you choose mac vs windows vs linus, maybe we move this guide to our docs so it can be dynamic html?
3. I think we should drop deno install --global --force --reload --allow-read --allow-write --allow-env --allow-net jsr:@valtown/vt from the installation step for clarity. I imagine 90+% of users just want the one install command.
4. Can we auto-run the authentication dialogue as soon as you install or is that a bad practice?
5. For shell newbs like me, it is no easy feat to add something to my PATH. How can we help folks with that step or can we skip it?

For reference, I think the vercel CLI is a good model for us. To install:

It's a single command that also exposing it globally.

In theory we could solve most of these issues if we made our CLI npm-installable. Is that a possibility? Are there other solutions in that direction?

[404Wolf]

Some thoughts!

1. I'm curious at what point they had the "I want this" moment. Did they notice the vt button on the website? Maybe on the onboarding flow we could say "Also, we have a CLI!"

2. Fair! There are a few solutions here:

   • "curl URL | sh": this is bad security practice and I don't like it, but it's common, this is what many programs use. The shell script is a big supply chain attack risk, but we could run the deno install command for their platform if deno isn't already installed, and then install vt afterwards. This also offers a nice path to run vt after to start the auth flow.
   • We could set up CI and list vt on popular package managers. Along the lines of homebrew, apt/nixpkgs, and chocolatey. Then they could just "brew install vt". This would be able to install deno too.
   • We could add vt to npm and use a script to install deno and then vt like you suggest. I think that this will slow down the startup time each time you run "vt"

3. Hm, sure. I would be a user who wants it, but I can understand it is very verbose. It is still a single command. I can remove it though!

4. Yes running a binary on install is probably bad practice. We could maybe do it if we choose option 2) a/b though.

5. Option 2) a/b lets us do this automatically but we have to "guess" what it means to add it to their path. For example, some people don't use zsh, etc. I would say that in the case we have someone installing on macos and they do have a .zshrc, we could append it. If they had their npm bin folder in their path then they would get this too that way.

[tmcw]

I think that getting to a better point in distribution, using deno compile to build a standalone executable is the highest leverage first thing to do: this would insulate us from system Deno versions, make it very possible to install with npm, and open the door to package managers.

I think the only blocker for using deno compile is that vt uses localStorage, which isn't available for compiled binaries: https://docs.deno.com/runtime/reference/cli/compile/#unavailable-in-executables

[404Wolf]

I think that getting to a better point in distribution, using deno compile to build a standalone executable is the highest leverage first thing to do: this would insulate us from system Deno versions, make it very possible to install with npm, and open the door to package managers.

I think the only blocker for using deno compile is that vt uses localStorage, which isn't available for compiled binaries: https://docs.deno.com/runtime/reference/cli/compile/#unavailable-in-executables

Yes, I set up compile CI a while back but we decided to just use deno install at the time -- it is true that deno doesn't support it right now but I've come across this which we maybe could use.

The thing is that (I think) we do really want the user to have deno installed. For deno lsp, formatting, updating packages, etc. I think that it makes sense to try to get them to install deno.

[tmcw]

I think that even if we do want the user to have deno installed, making that a requirement off the bat makes onboarding harder, and running any kind of package with a system-wide dependency is a pretty common source of instability. I think really it should be possible to gradually adopt this and a first step in which people have half-baked setups is going to be pretty useful for that.

[tmcw]

Just wrote #202 to nix the localStorage use and use a JSON file in the config directory instead - could be nice to at least have the option to compile if it makes sense for us.