Consider using TS/JS for action source code

[jcbhmr]

Yeah, if the logic gets too complex (or we have a compelling reason for using a library from the JS ecosystem), I'll definitely convert this to a Node.js action. That's what I did for https://github.com/spenserblack/actions-tag-to-release

Not sure if I'd use JS or TS, though 🤔

I think we are approaching this point.

• need to parse and transform urls and bash doesn't really cut it
• js has a builtin new URL() url parser
• js can auto-escape parts of a url when doing new URL().password = getInput("token")
• we can use try {} finally {} control flow to cleanup things
• try-finally flow in bash is hard
• we are using exit-early tactics COMBINED with the need to cleanup some stuff which is getting more complex in bash

---

Of particular interest is Deno! You don't need to compile TypeScript ➡ JavaScript, so you can just literally deploy raw .ts files (typechecking is disabled by default; add deno run --check to typecheck at runtime) or if you really want, you can deploy a NATIVE BINARY for each platform!

Point is, this would work!

runs:
  using: composite
  steps:
    - uses: denoland/setup-deno@v1
    - run: deno run -A demo.ts
      env:
        INPUT_REPOSITORY: ${{ inputs.repository }}
        INPUT_TOKEN: ${{ inputs.token }}
        INPUT_PATH: ${{ inputs.path }}
        INPUT_COMMIT_MESSAGE: ${{ inputs.commit-message }}
        INPUT_DRY_RUN: ${{ inputs.dry-run }}

// demo.ts
import { getInput } from "npm:@actions/core"

type LookMom = "types" | "!" | null | number;

console.log(getInput("token"));

look at that! no compile step!

---

Or we can stick with the tried-and-true Node.js path. This also allows up native access to the post-action hooks (so does Docker, but Docker doesn't work on Windows runners). https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runspost

Here's some supporting tooling for JavaScript/TypeScript-based actions:

• https://github.com/int128/release-typescript-action#readme
• https://github.com/JasonEtco/build-and-tag-action

The challenge seems to be how best to handle the dist/ folder for releases

[spenserblack]

IMO I'd want to stick with the "tried and true" Node.js runtime. I'd rather avoid setup- steps in this action (or any action), because I think actions shouldn't pollute environments and be as self-contained as possible. So if we use TS/JS, I think we should switch from a composite action to a using: node16 action.

As far as dist/ goes, I'd do what I did in this action: require that dist/ is built before committing to main. This allows @main to be used if a user wants to use the "bleeding edge" version.

I suppose the question from here is TS or JS? TBH I've started growing away from TS -- when you know what you're doing, it can make the dev process feel cumbersome. I like types for communicating intent (I'd love if this proposal landed), not so much for providing confidence that the code is written properly. However, having one syntax to write is nice. With JS you then have to ask "do I use .js, .cjs, or .mjs?"

So I'm on the fence right now about TS vs JS.
Anyway, regardless of TS vs JS, here's my wishlist for tooling:

• Jest for testing
• Prettier for formatting
  • If we adopt prettier, I'd want to revisit the styling. I don't really like throwing <formatter>-ignore comments in several places. I'd rather disable formatting as an exception, not as a rule.
• pnpm for dependency management
• If ESLint is used, don't use a super-strict set of rules like Airbnb. I used to default to using that, but some of the rules that sounded good in theory didn't hold up in practice (and clashed with TS). Frankly, I'm fine if ESLint is excluded.

[jcbhmr]

Because of this:

Deno works on macOS, Linux, and Windows. Deno is a single binary executable. It has no external dependencies.

The installer isn't very invasive or complex. You can set the install spot to be the GitHub action folder so that you could do "${GITHUB_ACTION_PATH%/}/deno" run -A ...

runs:
  using: composite
  steps:
    - run: |
        export DENO_INSTALL="${GITHUB_ACTION_PATH%/}"
        curl -fsSL https://deno.land/install.sh | sh
        "$DENO_INSTALL/bin/deno" run -A "${GITHUB_ACTION_PATH%/}/src/index.ts"
      env:
        INPUT_REPOSITORY: ${{ inputs.repository }}
        INPUT_TOKEN: ${{ inputs.token }}
        INPUT_PATH: ${{ inputs.path }}
        INPUT_COMMIT_MESSAGE: ${{ inputs.commit-message }}
        INPUT_DRY_RUN: ${{ inputs.dry-run }}

But alas, you're right, it's not popular at all.

[jcbhmr]

actually you know what... we could do what yarn and gradle do! put the binary (or a wrapper/installer script) literally in the git repo lmao

https://stackoverflow.com/questions/20348451/why-should-the-gradle-wrapper-be-committed-to-vcs
https://yarnpkg.com/features/zero-installs

[spenserblack]

I've used yarn zero-install before, and it is a really intriguing idea, but it can seriously increase the repo size. There's a sort of middle-ground with Yarn v2+ with node_modules, where you still get .yarn/releases/yarn*, so you technically don't need to install yarn. However, I don't think much is gained there, at least not for users. I'm very heavily leaning towards bundling all node modules together with @vercel/ncc, and having dist/index.js be the entrypoint for a node16 action.

[jcbhmr]

@spenserblack actually, with my primary concern of parsing a url-like string no longer relevant thanks to #67 and #68 i think we can/should stick with basic bash for a while longer

i was originally concerned that the complexity of string & url manip here would be unmanageable in bash

repository: jcbhmr/my-mega-project
repository: github.com/jcbhmr/my-mega-project
repository: github-enterprise.com/jcbhmr/my-mega-project
repository: http://gh.enterprise.com/jcbhmr/my-mega-project
repository: https://github.enterprise.com/jcbhmr/my-mega-project

[spenserblack]

Sounds good. If things start getting complicated, we can reopen this discussion.
IDK about you, but I definitely prefer writing complex things in JS to bash 🙂

[jcbhmr]

im reopening this because of three factors combined that I think put us into js/ts territory:

1. using try-finally logic to cleanup the .git folder after pushing
2. proper ::warning:: etc logs that are offered in actions/core pkg as core.debug() and others
3. potential erroneous github-server-url GH_HOST extraction (URL parsing again 🙄) https://github.com vs https://github.com/

I think that if we only needed 2 of the 3, id still say stick with bash, but all combined? that's a bit much.

@spenserblack thoughts?

[jcbhmr]

im on the edge here. all three of these problems CAN be solved in bash, but its a lot of hodgepodge complexity that needs a 2:1 comment:code ratio to make sense to your average dev.

[spenserblack]

I think go for it. The longer we postpone any rewrite, the harder it will be. And the more complex this gets, the harder to write in Bash (or any other shell).

I'll be away from my main PC for a couple weeks, but I'd like to build out the project's skeleton to get everything set up. I'll probably put it in a branch called js or something.

[jcbhmr]

btw heres a real world example of a .yarn/releases/* gh repo: https://github.com/ng-bootstrap/ng-bootstrap/tree/master/.yarn

[jcbhmr]

we could also use a deno wrapper like ./gradlew does where it:

The recommended way to execute any Gradle build is with the help of the Gradle Wrapper (in short just “Wrapper”). The Wrapper is a script that invokes a declared version of Gradle, downloading it beforehand if necessary. As a result, developers can get up and running with a Gradle project quickly without having to follow manual installation processes saving your company time and money.

basically use local, download if needed

here's a ./denow ideaa: https://github.com/chibat/deno-wrapper

steps:
  - run: ./denow index.ts
    shell: bash

[jcbhmr]

i dont know if this properly passes through the env vars to the bash shell. like $INPUT_PATH is what core.getInput() uses to fetch inputs, and I don't think there is implicit forwarding of those in composite actions. 🤔

basically we might be stuck either manually passing in all INPUT_* vars or just giveup and use node16

[jcbhmr]

yeah the INPUT_* vars would need to be manually passed through
actions/runner#665

[jcbhmr]

turns out it's not too bad! I did all the things that I thought would be tough and it worked out great in Bash. Keeping it simple and using default values that you can just pass through and not do if (thingIsEmpty()) { dontDoIt() } every time was nice!

https://github.com/Andrew-Chen-Wang/github-wiki-action/releases/tag/v4.0.0

• using try-finally logic to cleanup the .git folder after pushing ➡ use trap ASAP! not later. cleanup unconditionally. it's simple enough to rm -rf so that works here. if this were more complex, thenyes js/ts would be more appealing.
• proper ::warning:: etc logs that are offered in actions/core pkg as core.debug() and others ➡ just put up with the echo '::warning::Message here' style. or just use default stdout with no ::warning:: markers.
• potential erroneous github-server-url GH_HOST extraction (URL parsing again 🙄) https://github.com vs https://github.com/ ➡ just explain it well. assume well-formed input. if it errors out, that's on you the CI-configurer, not on my bad input handling 🤣

gist is that this CAN BE DONE and DONE WELL and READABLE in bash and we don't need js/ts yet. hopefully never considering the scope of this github wiki action

but you never know! 🤷‍♀️

marking as resolved for now. open later if this arises again.

[spenserblack]

Don't disagree, but I think TS/JS can make testing a lot easier. For example

// this is some made up testing framework, not representative of anything
describe('makeCommit', () => {
  mock(internals.makeCommit);
  test('it makes a commit allowEmpty is true', () => {
    // do stuff
    assert(internals.makeCommit.isCalled);
  });
});

[spenserblack]

Rewritten with TS. With this the freeze for features and bugfixes is over.