Deno support

[aaronhuggins]

• Adds Denoify to build so that this can be eventually deployed to https://deno.land/x
• Add a prebuild cleanup script
• Switched from process.nextTick to queueMicroTask; there should be no difference between the two methods so long as queueMicroTask is used exclusively instead of mixed with process.nextTick. Admittedly, my reasoning could be faulty as the choice of nextTick is not apparent. However, this minor (to me) change allows completely isomorphic code between Node, browser, and Deno

Very cool project, hope you don't mind the follow-up tinker. I love Deno, and a quick glance showed me this might be easy to support.

[Ethan-Arrowood]

Do we need to commit the build directories? I'm happy to support Deno but I'd like to not have to have build outputs committed to source control

[aaronhuggins]

Do we need to commit the build directories? I'm happy to support Deno but I'd like to not have to have build outputs committed to source control

There's really two options I'm familiar with that the community uses widely:

• Publish directly to Deno's third party module registry, requires Github w/ webhooks. https://deno.land/x#info Example: https://github.com/aaronhuggins/pouchdb_deno
• Nest.land is gaining traction in the community, and does not require Github (or any git/vcs for that matter). However, there's far more installation and configuration involved, including getting and maintaining an API key. https://docs.nest.land/eggs

I think the easiest to maintain would be a deno_build folder committed to the repo. The benefit of that strategy is no other installed executable is required on a machine/pipeline, no config files to manage, etc. I've found it to be relatively painless, as I just tag a release and it's picked up in the module registry.

[Ethan-Arrowood]

In that case, could the build be pushed to another branch?

I.e. an action that on merge or commit to main builds, commits, and tags to a branch called "deno"?

As someone who doesn't use deno I have little interest in having to deal with build files in source control I cannot manage. (Just as I wouldn't expect a non TS user to have to deal with my TS file build outputs unless they are strictly using the library)