refactor: re-write the cli from scratch in Go

[dcdunkan]

Requested by @Satont, to move the code from dcdunkan/gmy to here. (I'm not really good at Go).

Need to add workflows to create executables.

[Satont]

Thank you for your input! I'll take a closer look later, but at first glance the code looks great. The only thing is, I'm thinking about sewing templates.json along with the binary we'll be providing to our users.

I forgot to mention, I want us to ship binary for all platforms at once (macos, linux, windows, arm, amd64). It is easy with github actions i guess, i have expirience in golang with that. This will allow users to quickly install our cli using deno/node/go (yes, I want to keep that option too. So that it's fashionable to install via go install).

Also, an issue we should be concerned about is how to supply the binary for the deno environment. I mean, I want users who may not have a nodejs but have deno to be able to use our cli. I know how to make a binary for nodejs as an npm package, but not for deno. So I would like to invite someone like @KnorpelSenf to this PR , or he can indicate who can help with this.

And one more thing: we need to figure out how to do self-updater for the binary. I mean when we do new release and user have outdated binary, so we just update binary and run it on the user side, without needed manual steps to do that.

[KnorpelSenf]

I think @trgwii knows a fair bit of calling into binaries from Deno. Do you have any input here?

[dcdunkan]

The only thing is, I'm thinking about sewing templates.json along with the binary we'll be providing to our users.

But then users won't get the latest list of templates. That is why I made it fetch templates.json each time they create a project.

This will allow users to quickly install our cli using deno/node/go

Deno/Node 🤔? Why would we need that, isn't a go build binary enough?

[Satont]

But then users won't get the latest list of templates. That is why I made it fetch templates.json each time they create a project.

Thats what self-updater will do. Fetch templates takes time, we can speed up that. I guess thats ok release new tag when templates.json updates.

Deno/Node 🤔? Why would we need that, isn't a go build binary enough?

Yep, but you need to install that binary somehow. You can do that with node totally fine, distribute binary as npm package. But i'm not sure about deno.

[dcdunkan]

Fetch templates takes time, we can speed up that.

Yes, but not that much though. We can maybe have different templates.json files for each platforms. So, we only have to fetch templates for the specified platform. That should reduce time effectively.

I guess thats ok release new tag when templates.json updates.

That'll be a lot of tags, right? And since the codebase of the actual application have not much changes other than just an updated list of templates, isn't it kind of unnecessary?

Thats what self-updater will do

AFAIK, for such a self updater to work, it needs to check latest tag/release on GitHub. That takes time. And if there is a new release, it needs to download the new version, which I think about a <10MB file. (After downloading it to the path of current process executable (os.Executable()), the process needs to be restarted) I personally think fetching templates is much better easier than this. However, thats just my point of view. I'm open to more suggestions.

but you need to install that binary somehow

Just simply give them a installation script (https://grammy.dev/install.sh) like Deno (https://deno.land/install.sh)? Or download from GH releases? 👀

Add a update/upgrade subcommand, so users can manually update. Or, after creating a project, before exiting the app, we can check for new releases and tell them to do gmy update/update if there's an update.

[Satont]

Fetch templates takes time, we can speed up that.

Yes, but not that much though. We can maybe have different templates.json files for each platforms. So, we only have to fetch templates for the specified platform. That should reduce time effectively.

I guess thats ok release new tag when templates.json updates.

That'll be a lot of tags, right? And since the codebase of the actual application have not much changes other than just an updated list of templates, isn't it kind of unnecessary?

Thats what self-updater will do

AFAIK, for such a self updater to work, it needs to check latest tag/release on GitHub. That takes time. And if there is a new release, it needs to download the new version, which I think about a <10MB file. (After downloading it to the path of current process executable (os.Executable()), the process needs to be restarted) I personally think fetching templates is much better easier than this. However, thats just my point of view. I'm open to more suggestions.

Ok, thats all totally make sense, fetching templates is ok.

Just simply give them a installation script (https://grammy.dev/install.sh) like Deno (https://deno.land/install.sh)? Or download from GH releases? 👀

That means you need to write bash scripts for each OS, which i'm not familar in. Isn't just easier distribute binaries via npm/deno? For example there is task tool written in golang what can be installed via npm just fine.

Add a update/upgrade subcommand, so users can manually update. Or, after creating a project, before exiting the app, we can check for new releases and tell them to do gmy update/update if there's an update.

Atleast we should print user infromation anout there is new version, otherwise how did he know tools is updated. Manually visiting GH is bad DX.

Since golang is good in cuncerency we can do concurrent request on start for download templates and check does there new version released.

[dcdunkan]

@Satont Resolved every suggestions from your review.

That means you need to write bash scripts for each OS, which i'm not familar in. Isn't just easier distribute binaries via npm/deno? For example there is task tool written in golang what can be installed via npm just fine.

It is easy to distribute binaries via npm and deno, I agree. But if possible, we should also allow users to install the application using an installation script because it is more common. Others and I can maybe help you write scripts (mostly make small changes from existing scripts-like deno's script) if you also agree.

Atleast we should print user infromation anout there is new version, otherwise how did he know tools is updated. Manually visiting GH is bad DX.

Yes, that's what I said -> We could print that there is a new version available before exiting the application.

[KnorpelSenf]

I agree that the main way to distribute a binary should be through an installation script.

There are a lot of package managers for binaries, take Deno for example: https://github.com/denoland/deno_install#install-via-package-manager
We can discuss which ones to support, and npm can certainly be high up on that list, especially given how easy it is for us.

[Satont]

I agree that the main way to distribute a binary should be through an installation script.

There are a lot of package managers for binaries, take Deno for example: https://github.com/denoland/deno_install#install-via-package-manager

Not all users have installed 3rd party package manager, not all of them can install package manager.
For similar reasons we are not dropping nodejs 12 support in grammy core, because some of users just can't install/update soft they want to.

We can discuss which ones to support, and npm can certainly be high up on that list, especially given how easy it is for us.

True. Does deno install can install only typescript things, or it also can be used for installation of binaries?

For future discuss please move to telegram or to #18, because i'll merge that PR and finish some other work out of that.