Add Deno support with Denoify

[garronej]

Following up on #33,

As mentioned, it would be cleaner not to track the deno_dist directory on the main branch and publish with an action like tsafe or EVT does, I can help you with that if you want but I'd understand if you'd prefer not messing with your CI.

After merging what's left for you to do is to publish the module on the third party Deno module repository: Navigate to deno.land/x, click "Add a module" then follow the instruction. Use deno_dist/ as subdirectory when asked.

Best,

[gvergnaud]

Thanks for the PR, I'll take a look at this soon (sorry for the delay, I'm kind of busy lately)

[garronej]

I know what it is. In your own time!

[gvergnaud]

Hey!

I agree it would be preferable not to track the deno_dist build. Since I'm not so familiar with github actions, so I'd be super interested if you want to setup a basic action to publish new version to deno automatically. If it's too much work, I'll just merge this PR.

Quick question, are we still going to need a special build once deno starts supporting npm modules natively as announced here?

[garronej]

Hi @gvergnaud !

Quick question, are we still going to need a special build once deno starts supporting npm modules natively as announced here?

Good question, theorically no, but I want to use ts-pattern as a dependency for EVT and from a 'marketing' standpoint, offering a Deno module that depends on NPM packages... it's not great.
Also I would like EVT to remain retrocompatible with current and older Deno version.

Regarding the CI I'm very glad you asked!
It's much better not to track the deno_dist and since you do not have a CI workflow already I was able setup it up quickly.

What the CI does:

• On every commit:
  • It runs the test on Node
  • It checks that, type wise, the Deno distribution is OK
• If all tests passes it checks if the version number in the package.json have been updated if yes, it release on NPM and update the latest branch that will be used as target for GitHub release tags.

What you need to do:

• Create a GitHub action Secret NPM_TOKEN that contains your npm token. You can get this token on npmjs.com:
  
• Whenever you want to publish a new version you'll just have to update your package.json number push and wait.

• Publish the module on the third party Deno module repository: Navigate to deno.land/x, click "Add a module" then follow the instruction. Use deno_dist/ as subdirectory when asked.

If you have any question, I'm here to help!

[garronej]

Hi @gvergnaud,

A quick up just in case you forgot this PR :) Let me know if you have any question or concern.

Best,

[gvergnaud]

Hey @garronej, I haven't forgotten your PR!

I'm sorry for the delay, I just didn't have the time to read and understand your github action config and I didn't want to merge something I won't be able to maintain.

I have a few questions actually:

Whenever you want to publish a new version you'll just have to update your package.json number push and wait.

1. I often start by releasing a RC version with the tag @next, how is it going to handle those versions?

2. Is this action only going to be triggered on the main branch or on all branches?

3. ~~when I enter ts-pattern in https://deno.land/add_module it says that the name has been taken. Do you know if there is a way to claim this name?~~ It looks like deno doesn't support dashes in names 🤔

[garronej]

Hello @gvergnaud,

I'm sorry for the delay, I just didn't have the time to read and understand your github action config and I didn't want to merge something I won't be able to maintain.

Understandable. Anyway I'll always be there to assist you if you have any problem with the CI setup.

I often start by releasing a RC version with the tag @next, how is it going to handle those versions?

~The way this is hanled is, if you update your package.json's version with something like 4.1.0-beta.0 it will create a pre-release on GitHub and release on NPM.~

~It's basically the same as what you are curently doing but with beta instead of next.~

~If you want I can update ts-ci so that it work with next as well.~

Is this action only going to be triggered on the main branch or on all branches?

It tirggers only on the main branch and on the branches of the repo that have an open PR on main. Branches of forks that have an open PR on main will only be able to run the tests but not to release (obviously).

It you want this action to run on a branch that has no open PR on main you can simply edit this line, replacing main by the name of the branch.

It looks like deno doesn't support dashes in names 🤔

Yes, Ryan Dahl wanted it this way. You'll have to use ts_pattern or tspattern either way Denoify will be able to automatically resolve your deno distribution.
Examples with a run-exclusive import in EVT automatically replaced by an import of run_exclusive from deno.land/x.

Best regards,

[garronej]

I have put this PR in draft while I update ts-ci to better acomodate your current workflow.

[garronej]

Hi @gvergnaud,

often start by releasing a RC version with the tag https://github.com/next, how is it going to handle those versions?

You can do that by updating the package.json's version to X.Y.Z-rc.U, it will create a pre-release on GitHub and publish on NPM a version X.Y.Z-rc.U with the next tag.

[gvergnaud]

It tirggers only on the main branch and on the branches of the repo that have an open PR on main. Branches of forks that have an open PR on main will only be able to run the tests but not to release (obviously).

You can do that by updating the package.json's version to X.Y.Z-rc.U, it will create a pre-release on GitHub and publish on NPM a version X.Y.Z with the next tag.

Awesome, thanks!

[garronej]

Hi @gvergnaud,
Thanks for taking the time to review this!
I've done my best to smothen things up and make the workflow as transparent as posible.
I've created a copy or the ts-pattern repo, renamed the library fuzzy-octo-guacamole.
Here is an invite you can play around with it, upgrade the package.json's version number and see how fuzzy-octo-guacamole is published both on npm and deno.land/x.
Do not hesitate to create PRs from branches with package.json version like 2.0.0-rc.0 to see a pre-realase being created.

The main takeway is, when we want to release:

1. We create a tmp_branch
2. We build locally, there by creating the deno_dist/ directory.
3. We remove /deno_dist from the .gitignore
4. We commit all deno_dist/* files (the commit exist only on the tmp_branch).
5. We create a new GitHub release targeting tmp_branch
6. We release on NPM
7. We remove the tmp_branch

And voilà! We have the directory deno_dist/ present in our git tags but not on the main branch.

Les me know if you have any question, we can schedule a call.

[garronej]

Hi @gvergnaud,
Is there something that you don't like in this template?
If yes tell me and I'll try and improve it.
If it's just that you didn't find the time to review, no worries, take your time!

[gvergnaud]

Hi, Thank you for creating a test repo with the action enabled! Unfortunately I didn't have the time to test it and your invitation has expired. Could you invite me again? I'd like to move forward with this PR this week

[garronej]

Thhere you go: https://github.com/garronej/fuzzy-octo-guacamole/invitations :))