Cache the installation to avoid redownloading & switch to Node.js

[jcbhmr]

👋 Hello @yusancky!

I'm opening this PR because this seems to be the premiere Typst-installer GitHub Action. However, it doesn't cache the installation which is a big downside. Then after adding caching support I got carried away and did a bunch more stuff lol. 😅

This PR would:

1. Add caching support. If the typst cache dir exists, don't download and extract it again; just use the cached dir.
2. Add support for ARM64 runners. This is important with self-hosted GitHub Actions runners that run on ARM64 images like those from https://buildjet.com/for-github-actions or others.
3. Add a GitHub Action to test and make sure that PRs and main commits actually work. Basically it just runs the action and then typst --version and typst compile test.typ to make sure it works. https://github.com/jcbhmr/setup-typst/actions
4. Use the Node.js runtime instead of a composite action. This was needed to get tight integration with the existing GitHub Actions SDK provided for Node.js-based Actions.
5. Use Vite to bundle the Node.js code on release into a self-contained JS file. GitHub Actions Node.js runtime doesn't do npm install && node main.js, it just does node main.js. Therefore, you need to bundle all your dependencies.
6. Use post-release tag mutation to build & commit the dist/main.js bundled Vite artifact on each new release.
7. Improve readme to describe inputs and outputs a bit more thoroughly.
8. Bump the version used in the readme from v2 (current version) to v3
9. Add a GitHub Action to automagically tag new releases with a major tag (vN) in addition to the specific tag (vN.N.N).

[yusancky]

Thank you very much for contributing. I checked out the discussion you posted too, and I'll give 'em both a good look-see over the weekend.

To tell you the truth, I originally wrote this action just for my own use. I was thinking about making this project in Node.js before, but I had trouble with downloading releases back then.

[yusancky]

Thank you very much! Taking advantage of my free time today, I have thoroughly reviewed your contributions.
Additionally, I am considering adding you as a collaborator (and even including you in the license if you wish), what do you think?

[jcbhmr]

Additionally, I am considering adding you as a collaborator (and even including you in the license if you wish), what do you think?

Sounds great! 👍

I also want to bring up: I think that this setup-typst GitHub Action would be a great project to put under the @typst-community organization. IMO it would be best to coincide that with the release of v3 of this action. Do you think that this would be a good move?

^{Sidenote: GitHub will redirect Actions to their new name no problem}

[yusancky]

So I just need to do this to transfer to @typst-community then?

[jcbhmr]

Pretty much!

• In order to transfer a repo to an org you do need to be an org member. @huwaireb is currently the person with the power to add members. 👋 Hey @huwaireb, I think you should add @yusancky as a member to @typst-community 👍
• Anyone browsing to https://github.com/yusancky/setup-typst will be redirected to ${new_url}
• Anyone with - uses: yusancky/setup-typst@vN will redirect to - uses: ${new_repo}@vN
• You should still have full "Owner" role of the transferred repository's ${new_url}; contact @huwaireb if you don't

That's the gist of it. I did ☝ with https://github.com/typst-community/typst.js and it worked out pretty well so far. 🤷‍♂️

Then once you're ready (after transferring or not transferring if you decide that) create a new GitHub release via the GitHub UI with a tag of v3.0.0 and watch the magic happen 🎉

[huwaireb]

Hey 👋,

Came here to confirm on the request of @jcbhmr,

@yusancky, do you want to drop setup-typst in the typst-community org? I'm questioning if you, personally feel like you'll benefit in any way in doing so if the organization itself cannot offer anything right now, as it is just an aggregrate of community projects. However, it does have goals, close to that of other *-community organizations.

Take @coq-community for one, for reasons why you could want to have a repository on *-community organization (from github:coq-community/manifesto):

• the initial author has stopped maintaining the project and someone else is volunteering to do so;
• the project has become a collective work (several community members are actively working on it);
• the initial author is still maintaining the project but they want to encourage other community members to participate in the maintenance and possibly take over (and the project is indeed raising interest from the community);
• the project is a tool of general interest and it makes sense to develop it collaboratively.

If you have no interest in doing so, it's completely fine. If you do, then I'll proceed by extending an invite.

context

@jcbhmr's reach out, was if my understanding is correct, purely with the thought that such project, a setup-typst action, would be ideal for a place like @typst-community, and did not want to cause fragmentation in the community by creating a new one so he opt'd for a PR instead, in place extending an invite to participate in an arguably environment that gains from centralization in many things, one being collaborative-ness.

[yusancky]

Do you want to drop setup-typst in the typst-community org?

@huwaireb Sure, I'd be happy with that!