Fix deno release flow and publish two packages

[scotttrinh]

We are currently not automatically publishing releases to deno.land during our release. We're also only publishing a single package that represents the driver, so we should also publish the generator package.

[jaclarke]

@scotttrinh Just in case this is useful:

The rough plan I had for splitting edgedb-deno into two packages was to re-organise the repo into two root directories: driver and generate, remove the current webhook (https://github.com/edgedb/edgedb-deno/settings/hooks), and replace that with a github action that would similarly be triggered on tag creation and mimic github's webhook call, but would decide which webhook (https://api.deno.land/webhook/gh/edgedb?subdir=driver or https://api.deno.land/webhook/gh/edgedb_generate?subdir=generate) to call based on the tag prefix.

Since it's very possible that this won't work for some reason, the fallback idea was to just create another repo for the edgedb-deno generate package, and use the normal webhook. But I felt like trying to keep it to one repo first was less stuff to duplicate and maintain.

[scotttrinh]

@jaclarke

that would similarly be triggered on tag creation and mimic github's webhook call, but would decide which webhook

This is a clever solution! I'm definitely worried that since this isn't documented, that they'll have some kind of shared token to ensure that the call is coming from GitHub that would make it harder to publish. I'll do some more digging here.

My current plan is to investigate having a single version that all packages share which will solve the short-term issue with the tagging structure and ambiguity in Deno. It's worth understanding the deno.land publishing flow a little better anyway, though, so I'll see what I can find about this.

[denizdogan]

While waiting for this to be changed, is there anyone I could bribe to publish v1.2.2 to deno.land?

[scotttrinh]

@denizdogan

I'm going to try to manually publish a release!

Out of curiosity is it possible to use github directly instead of deno.land? I imagined one of the advantages of "use fully qualitified URLs as packages" was that one isn't tied to a package repository and could import directly from any public URL? Mostly, I'm just wondering how "stuck" deno users are as we're working out the publishing story here.

[denizdogan]

@scotttrinh Thanks a lot!

It's definitely possible to use "raw" GitHub URLs. There's many reasons not to:

• GitHub repos can be deleted (and often are) – deno.land/x remains
• GitHub URLs tend to default to the latest main commit, which is not great practice
• GitHub URLs are long to the point where the import is unlikely to fit in one line
• Users have come to expect that packages that explicitly support running on Deno will be published on deno.land/x
• Etc.

If I may ask, what are the customizations that your Deno builder does? Could some of it be replaced with just Denoify? If you can make this work well with Denoify, I think you could just use the normal deno.land/x Git tag publishing hooks.

[scotttrinh]

@denizdogan

If I may ask, what are the customizations that your Deno builder does?

https://github.com/edgedb/edgedb-js/blob/master/compileForDeno.ts

Could some of it be replaced with just Denoify?

I would love to know! I'm not a Deno expert or even a Deno user, so we're very open to getting help from the Deno-using community in this regard. PRs or guidance welcome.

If you can make this work well with Denoify, I think you could just use the normal deno.land/x Git tag publishing hooks.

I think I want to solve for #626 anyway, so hopefully some of this becomes moot. We have more packages coming in the future, and having a consistent version number seems like it'll just help with deno publishing. I can't seem to find much about publishing to deno.land from monorepos though, so would love to know more about this as well.

---

It's definitely possible to use "raw" GitHub URLs. There's many reasons not to:

Note that even though I published a new release and tag on https://github.com/edgedb/edgedb-deno , for some reason the webhook didn't fire so the new version isn't published to deno.land yet 😞

I think the solution of pointing directly at github might be the short-term fix until we get the deno publishing flow working again. I think this is the right URL for the 1.2.2 mod.ts: https://raw.githubusercontent.com/edgedb/edgedb-deno/71606180fffd326d77be5ea5c5e928bd9e0237b7/mod.ts

[denizdogan]

@scotttrinh I don't know what's happened since you replied, but it looks published to me: https://deno.land/x/[email protected]

Current version released 56 minutes ago

I'll see if I can't simplify the build process using Denoify at least somewhat, but just as you are not a Deno expert, I'm not an EdgeDB expert :)

[scotttrinh]

Oh, excellent news! Looks like the webhook just went out about 58 minutes after the tag was created. 😬

I'll see if I can't simplify the build process using Denoify at least somewhat, but just as you are not a Deno expert, I'm not an EdgeDB expert :)

Would very much appreciate any help on this front you can provide. Hopefully you won't have to know much about the internals of the codebase, but if you do, maybe I can pick up where you leave off?