We Keep Coding

What is regenerator-runtime npm package used for?

I've noticed it in my company's codebase and it has 30M downloads per week so I'm curious about its importance.

regenerator-runtime is the runtime support for compiled/transpiled async functions. (It may well have other uses, but this is the predominant one.)
When you use a compiler like Babel that compiles modern JavaScript into earlier JavaScript (a process sometimes called transpiling), one of the things you can do is compile async functions to something that will run on JavaScript engines that don't support async functions (such as the increasingly-irrelevant IE11). Babel does the syntax transformation, but the resulting code relies on runtime support from regenerator-runtime.

Has anybody separated TypeScript from Node?

I'm working with V8 in C++ and was asked about supporting TypeScript, which I'm unfamiliar with. After poking around, it looks like TypeScript runs as JavaScript but seems pretty tied to Node (e.g., for accessing the filesystem). There is no O/S filesystem in my project, which doesn't bother V8 because it isolates itself from such things and lets me translate things like "module names" into database calls rather than filesystem reads.
I see Deno also embeds TypeScript, but since its the same guy that wrote Node, I'm guessing that was a big leg up in providing TypeScript all the Node-cruft it has its hooks into. Seems a shame that TypeScript runs as JavaScript but ends up tied to a particular project rather than being embeddable in any JavaScript environment.
Has anybody written a neat shim for insulating TypeScript from Node to reduce the work of embedding it in a different product? Any ideas/pointers/thoughts welcome...
To be clear: I mean to say "separate the TypeScript compiler from Node". And by embed Typescript, I mean "embed the TypeScript compiler", which I believe is (in its compiled form) a bunch of JavaScript with serious dependencies on Node.

TypeScript already is separated from Node. In fact, it has nothing whatsoever to do with Node.
As an example, see the TypeScript Playground, which is an online IDE written in TypeScript that runs in the browser (no Node in sight), including embedding the entire TypeScript toolchain (compiler etc.) which is also written in TypeScript and also runs in the browser (again, no Node in sight).
In fact, I wouldn't be surprised if while you were writing this question, there was actually TypeScript code running in your browser without Node. (Stack Overflow, Inc. is known to use TypeScript.)
You already mentioned Deno yourself, which includes the TypeScript compiler. No Node in sight.
Many, many web companies all over the world are using TypeScript to do browser-side scripting. Again, no Node in sight.
There is exactly one Node-specific thing in TypeScript, and that is that TypeScript knows how the Node.js module-lookup algorithm works. The only reason this exists is to ensure that if you use Node-style module lookup in your code, TypeScript will use the same algorithm to find the module for type-checking at compile time that Node.js will later use at runtime. Otherwise, it could lead to the situation that TypeScript will at compile-time find a module, type-check it and determine that is type-safe, but then at runtime, Node.js would actually load a different module.
This is undesirable, and that's why TypeScript knows about the Node.js module lookup algorithm. If and when another module lookup algorithm becomes popular, TypeScript will probably also implement that one. It doesn't seem likely, though, since e.g. the ECMAScript committee and the Denon developers have deliberately chosen to design much simpler module lookup. (In fact, ECMAScript and Denon arguably don't have "module lookup" at all, you always need to specify a URI resolving to the exact location of the module file.)
!!! NOTE !!! Whenever I wrote about "running TypeScript code" above, that was a simplification. As far as I know, there does not exist an interpreted TypeScript implementation, so you actually can't "run TypeScript" (in the same sense that you can't "run Go"). You have to compile it first. There are currently two compilers for TypeScript, tsc from Microsoft, and the TypeScript plugin for Babel. Both of those compilers compile TypeScript to ECMAScript. Also, both are delivered in ECMAScript (although tsc is written in TypeScript).
So, as long as you have some way of running ECMAScript, you can also run TypeScript.
There was a project to implement a native TypeScript implementation on top of the Rubinius Language Framework, but that project literally never produced more than a README stating the intention of implementing a native TypeScript implementation on top of the Rubinius Language Framework. I still think it would be nice to have a TypeScript runtime that isn't tied to ECMAScript, though.

Are there any javascript testing frameworks that natively support ES6 imports without babel or another transpiler?

I've developed a node 13.12 application that uses only ES6 style module imports. Given that it's 2020, I'd like to use a testing framework that can natively support those imports without requiring Babel or any other transpiling. Does such a framework exist yet?

At this point (May 2020) I have been unable to locate a testing framework that fits the bill. I ended up rolling my own rudimentary one, wasn't as hard as I thought. Just reimplementing some of the common paradigms like "expect equals" and "expect error". Enough to get some testing done and move on with the real work.

traceur compiler runtime vs build

As the ES6 spec is nearing completion, I'm investigating get a jump start on ES6 syntax and leveraging traceur compiler to do so.
My question is that I see that tracuer requires a 'runtime' file to be included on the page, is this a shim for some lacking 'core' features like Array/etc OR is this a runtime converter and then the build is just for deploying?
If its just a 'shim' per say, how do you deal with always compiling during development? I know you could do a watch in grunt but for large applications that seems very slow. I also saw you could use a node compiler, but node is not my backend/server tech ( I use IIS, ya i know ).
Thoughts/suggestions?

Module for ES6 features

Is there a JavaScript module, that can be installed in current versions of Node, that provides some ES6 features e.g. Map? (The version of Map provided by node --harmony doesn't yet implement enough features to be useful.)

This compatibility matrix should be of use.
Of particular interest, might be google's traceur compiler which will translate es6 code to es5 to run anywhere