feat: add deno entry

[lukeed]

First pass at a Deno entry.
All fs.* operations are available under Deno namespace.
Only had to import std:path module.

Questions:

1. Both Deno.* operations require the allow-read permission. Is this something I have to flag on my side?
2. Is there a better/built-in way to go from AyncIterator to Array?
3. Do I have to add /deno to my package.json files? Assume not since publishing works thru git releases only

//cc @bcoe

---

Closes #3

[codecov-commenter]

Codecov Report

Merging #4 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master        #4   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            2         2           
  Lines           20        20           
=========================================
  Hits            20        20           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 24efb4b...230627b. Read the comment docs.

[bcoe]

Both Deno.* operations require the allow-read permission. Is this something I have to flag on my side?

I've been capturing the error, and providing a useful note for users. It sounds like there is a way to prompt for permissions, might be a good option too:

https://dev.to/bmorearty/better-deno-security-ask-for-permission-at-runtime-1fnm

Is there a better/built-in way to go from AyncIterator to Array?

I'm not sure. Your approach seemed pretty reasonable to me 👍

Do I have to add /deno to my package.json files? Assume not since publishing works thru git releases only

No, you should be able to ignore /deno.

[bcoe]

This is looking good 👍 for yargs, I will need the sync option

I think, I'd be happy to pitch in if you run out of cycles this week.

[lukeed]

Thanks! I'll add extra sync entry. I figured everything would be async in Deno because of top-level await but obviously that was a bad assumption.

I think permissions is all that's left to solve. Catching it makes sense for a yargs but I don't think it would for every module down the tree.

Happy to focus on it this week. Would hate to be the blocker for your conversion effort

[bcoe]

@lukeed yes, let me know where you land on permissions, this is something I'm trying to learn to navigate too.

[lukeed]

Hey, so I asked the Deno Discord and the recommendation is to allow the permission errors to happen. Any required permissions should be listed in the README (or in the functions' jsdoc blocks), and it's ultimately up to the consumer to add the appropriate flags. This is also how you can get method/usage-driven granular permissions.

I found feature proposals in the Deno repo about adding manifests/import-map-like files to define the permissions ahead of time, but there's not been any action taken on them yet. Design still WIP