Look into supporting JS-based running of this function

[chinthakagodawita]

e.g. #282

This will conflict with #181 (and #272)

AC:

• A dist folder with the built JS of this action
• A CD workflow that updates the dist folder when changes are merged to master

[ken-matsui]

@chinthakagodawita
To respond to your question in #282 (review),

If you are hard to keep the dist directory up-to-date, then you just update the dist directory when autoupdate is released.

I think that you previously did the following steps:

$ git commit -am "release v2.0.0"
$ git tag v2.0.0
$ git push origin v2.0.0
$ docker build -t chinthakagodawita/autoupdate:v2.0.0 .
$ docker push chinthakagodawita/autoupdate:v2.0.0

However, I would say new steps are much simpler:

$ yarn build  # Outputs to the `dist`
$ git commit -am "release v2.0.0"
$ git tag v2.0.0
$ git push origin v2.0.0

For users, JS-based actions are faster than Docker-based actions because of no need for the docker pull process. JS-based actions can enforce matching the version and real data because we commit the dist directory. Therefore, JS-based actions can avoid the maintainers' possible mistakes such as a version mismatch between the Docker image and the GitHub Release. Additionally, if you want to invite a new maintainer, you will not need to grant access to DockerHub.

These are advantages of JS-based actions I think, but I ultimately would like to respect your opinion.