Given the rise of support in NPM compatibility, it feels a bit silly to entertain requests that are mainly about converting Y to Deno, when those types of issues should either be given to the original NPM module, or reported as issues for either Deno's npm compatibility library or esm.sh/similar vendors.
Instead, wanted modules should primarily be:
Deno specific libraries (e.g. an API that parses Deno tasks to run them in a Deno fashion)
Deno-enhanced ports (ones that would benefit from Deno, e.g. #40)
Library conversions from other, non-js languages (#68)
A lot of the conversations in the repository usually boil down to:
"I need from NPM, since doesn't work." (usually these issues were reported before the full adoption of npm compatibility)
Another user (or the same user) would usually either:
a. Recommend a different approach, or link it to the repo to add Deno compatibility
b. Find a workaround for their issue
The purpose of the repository is very nice (as it allows developers to find new ideas for Deno projects), but the redundancy of (very) big library ports in the face of Deno's NPM compatibility seems to be fit for reporting another repository (e.g. the recommended deno_std).
Given the rise of support in NPM compatibility, it feels a bit silly to entertain requests that are mainly about converting Y to Deno, when those types of issues should either be given to the original NPM module, or reported as issues for either Deno's npm compatibility library or esm.sh/similar vendors.
Instead, wanted modules should primarily be:
A lot of the conversations in the repository usually boil down to:
The purpose of the repository is very nice (as it allows developers to find new ideas for Deno projects), but the redundancy of (very) big library ports in the face of Deno's NPM compatibility seems to be fit for reporting another repository (e.g. the recommended deno_std).