How to use `yarn node` to spawn GitHub Action?

I’m trying to migrate from a mammoth main.js file that ncc concatenates together with all the node_modules dependencies to a simple main.js file by leveraging Yarn v2’s Zero Installs feature. But the only problem is that such an executable script must be launched with yarn node lib/main.js instead of just node lib/main.js in order for the node module resolver to find the checked in node module archives.

Is there a way in the action.yml file to make this work? What are the allowed values of the runs.using property? I know node12 works, but I suppose yarn node probably doesn’t work.

Is there any way this can be made to work?

Thanks for your feedback.
If you use yarn node property in your action.yml file, you will get the following error:
Parameter ''using: yarn node' is not supported, use 'docker' or 'node12' instead.' At the same time, this is also mentioned in the official document.

Sorry for that there is no ideas or workarounds at the moment. But I will continue to follow up on this. Thank you for your understanding.

Thanks for your reply. I can’t find in the official document where it lists the allowed values for the using property. But I guess it’s inferred by those being the only two values given in the examples.

FWIW I think I found a workaround: create a bootstrapper .js file that action.yml points to with this content:

const { spawn } = require('child_process');
const { argv, exit } = require('process');
const cp = spawn(`yarn node ${__dirname}/main.js`, argv.slice(2), { shell: true, stdio: "inherit" })
cp.once('exit', code => exit(code))

Setting this bootstrapper next to the main.js file that requires yarn node to run leads to yarn node being invoked as a child process and the action proceeds as planned.
But this took me a while to work out, so adding support using to be set to yarn node12 or something like that would be awesome.

Hi @AArnott,

In general I would recommend against that for an action. The dependencies still need to be downloaded and anyone using your action will take the full hit of the download of those dependencies on each run. This both introduces more points of failure as well as reduced performance.

1 Like

@chrispat thanks for chiming in!
This yarn node feature that I’m using does not restore packages first. It immediately runs my action with node. The only thing that yarn does is teach node how to find the packages that are all checked in. So this is essentially like the ncc world where node_modules is concatenated into one main.js file, except there’s no concatenation, and I don’t have to check in thousands of .js files under node_modules.
If you’re interested, you can learn more at the Zero Installs link I shared in my first post.

IMO it’s the best of both worlds: no restore necessary, but you still have reasonably sized .js files for your own code.

Where are the dependencies coming from then? Are you vending them into your repo? It is unclear to me how that is better.

The dependencies are ‘checked in’ to git. You can see them here in my github action repo.
Since checking in node_modules itself is certainly another possible way to solve this, what may be new to you here is that what yarn v2 Zero Install has me check in is the .zip of the dependencies instead of each file from the expanded zip.
Even outside the GitHub Action use case, the Yarn v2 crowd advocate Zero Installs as a reasonable way to use git and skip the long restore step. Since the .zip file is never expanded except at runtime, you don’t have to wait for the OS to unpack many thousands of tiny .js files to disk. I’m still not totally sold on checking dependencies into my git repos in general but for GitHub Actions where the repo must be ‘runnable from source’, it makes perfect sense.