patches: bump to 18.13.0, 16.19.0 and 14.21.2

[baparham]

All patches apply cleanly

[baparham]

@robertsLando can you give this a look?

[robertsLando]

LGTM

[leerob]

There are some steps here to verify the patches have been created successfully - can we try those?

And then let's document in the README those steps for the next PR 👍

#258

[baparham]

There are some steps here to verify the patches have been created successfully - can we try those?

And then let's document in the README those steps for the next PR 👍

#258

I've attempted to document this in #251 already, and followed my own docs to make sure the patches apply cleanly

[baparham]

There are some steps here to verify the patches have been created successfully - can we try those?
And then let's document in the README those steps for the next PR 👍
#258

I've attempted to document this in #251 already, and followed my own docs to make sure the patches apply cleanly

Meant to tag @leerob in this reply

[baparham]

@leerob I created a merged PR in my fork to test these patches against the new patch application test added in #251 so that we don't have to wait to get that merged in before testing this patch set with it.

all tests pass

[sobolk]

@leerob Could you publish this to npm ?

[danielleadams]

@leerob Could you publish this to npm ?

+1

[baparham]

AFAIK we can't publish until we get ARM support working, any help you can provide over in #276 would be greatly appreciated.

I agree that we need to publish this as soon as possible. In the meantime, there are a few workarounds suggested to build your own binaries in your own fork, and patch your local copy of pkg-fetch to support the specific versions added lately with their expected SHAs.

I'll see if I can post a quick, how-to for such a workaround in the next day or so in the meantime to sorting out the ARM builds.

[sobolk]

Thank you @baparham . A how-to for a workaround would be greatly appreciated.

[ashish-aws]

@baparham Brad, i can get you AWS credits. can you share your email address? For context, Kamil and I work in the same team.

[baparham]

@sobolk I'm still trying to find some time to document the details, but here is the top level summary. Each portion is surely searchable on your favorite search engine :-)

It basically boils down to these steps:

1. Fork the repo on GitHub
2. Enable actions in your fork in Settings tab
3. Kick off the build workflow for your target OS in GitHub
4. Download resulting binary(ies) locally from GitHub workflow artifacts
5. Patch your local version of pkg-fetch to support the new binary(ies) with
   the correct sha384 sums in expected.ts, and node version number in patches.json
6. Use PKG_CACHE_PATH to point out the local folder where your new binaries are stored as fetched-* (renamed from node-*)

[robertsLando]

Check this: https://github.com/yao-pkg/pkg-binaries#usage

Used it in a gh workflow here: https://github.com/zwave-js/zwave-js-ui/blob/master/.github/workflows/package_armv7.yml#L55