v0.2.0 breaks support for Deno versions prior to 1.17

[bennyvdhoogen]

Not sure how much of a priority backwards compatibility is in Deno land; but recently ran into an issue with this package on a bot that I have running in 'production' on AWS Lambda. I've uploaded the deno runtime binary some time ago and noticed today that it crashes on importing this package due to an unexpected assert statement(emoji.ts:4). I see that import assertions were added in Deno 1.17 and am certain the used runtime binary is from before that.

As Deno is quickly evolving I wouldn't want to advice against using newer features, but perhaps worth mentioning that this is a breaking change in the readme?

Note: in a node stack this would usually mean that the required node version is updated in the package.json. What would the node equivalent of locking a package to a Deno version be? The closing argument on denoland/deno#3155 suggests that authors write some sort of prompt manually?

[bpevs]

Oh shoot this wasn't an intentional deprecation; side effect of changing all.ts -> all.json.
I had switched to json, because it seemed like a more generic way to store large object blobs.
I didn't realize that import assertion was a new feature. 100% my fault.

I wonder if it's better to mention breaking change somewhere, or better to revert that part of the change to generating a .ts file...

[bpevs]

Could make change like:
main...bpevs:emoji:json-ts
?