Switch from Deno.run to Deno.Command

[shapirone]

Summary

With 1.33 came the deprecation of Deno.run, so we need to switch to using Deno.Command. This was stabilized as part of the 1.31 release, so we might want to wait a bit to allow folks time to upgrade their local version of Deno.

I was only able to get this to work through the spawn method to create a child process, I was not able to get output or outputSync methods to work.

Testing

Check out this repo and update your start hook to point to your local repo. If testing against a dev Slack instance, make sure to add the sdk-slack-dev-domain arg at the end

  "start": "deno run --config=deno.jsonc --allow-read --allow-net --allow-run <your-path-here> --protocol=message-boundaries --boundary=jkadfssajdflkjasdfjhdas"

Requirements (place an x in each [ ])

• I've read and understood the Contributing Guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.

[codecov]

Codecov Report

Merging #50 (f26bee9) into main (5f5fe4e) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #50   +/-   ##
=======================================
  Coverage   90.31%   90.31%           
=======================================
  Files          14       14           
  Lines         568      568           
  Branches      110      110           
=======================================
  Hits          513      513           
  Misses         54       54           
  Partials        1        1           

Impacted Files	Coverage Δ
src/local-run.ts	89.18% <100.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[shapirone]

One thing we should test around this is whether or not this leaves the process open or if we should close via something like subprocess.kill()

[filmaj]

Generally, once the status code from a process is able to be retrieved, this implies that the process completed, so my expectation is that we don't need to do that - but doesn't hurt!

[filmaj]

These changes look good to me overall but I am most concerned with how to roll this change out and how we coordinate / publicize / document the minimum deno version we support as well as how other hooks factor into this. So to be specific:

• Clearly document a minimum deno version on our docs somewhere. Likely in an initial Requirements page or some such.
• Adding a doctor hook for deno-slack-hooks to implement that can check the deno version, and make sure that is reported/raised properly by the CLI (HERMES-4989)
• The ROSI team is on board with publishing the deno version used in ROSI in e.g. our metadata.json API endpoint. All of the above, IMO, should consume from that endpoint to dynamically be able to check/publicize the recommended deno version to use.

[filmaj]

Generally, once the status code from a process is able to be retrieved, this implies that the process completed, so my expectation is that we don't need to do that - but doesn't hurt!