[dev-tool] Implement esModuleInterop for sample transpilation

[witemple-msft]

This PR implements some improvements to the way that the dev-tool sample transpiler handles default imports (import x from "x";). Currently, we simply don't allow these imports unless the module specifier refers to a node built-in module (in which case we treat it as if it were a require call), or if the module specifier is a relative path (in which case we use the default property of the module object).

This PR changes the behavior to emulate esModuleInterop at compile-time. When considering a default import, we will simply require the module from the host package and check for an __esModule property. If one exists, then we will transform the default import into a const <name> = require("<moduleSpecifier>").default expression. If one does not exist, then we will omit the .default and treat the import as if it were a simple require call. This mimics the actual runtime behavior of __importDefault generated by esModuleInterop:

var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};

In addition to this change, we also explicitly consider all modules in any @azure namespace to be ESMs without testing them. This supports RLC samples (CC @joheredi).

Incidentally, this also fixes an issue in which ambient .d.ts files in samples-dev would crash the sample transpiler, and it deletes the ts-to-js command (because it had fallen out of sync with the sample transpiler and is not in use).

CC @deyaaeldeen and @maorleger , as this PR addresses some issues you have seen.

Packages impacted by this PR

All of them, especially @azure/dev-tool.

Issues associated with this PR

Closes #18877
Closes #18878
Closes #19594

Describe the problem that is addressed by this PR

Several packages depend on modules that aren't supported without proper default-import and esModuleInterop functionality:

• Rest-level clients, which use export default as part of their programming confention.
• CJS modules that assign a class to module.exports, which can only be constructed if imported as a default import (example: "ws", the most common websocket implementation, which is used by the event-hub samples).

This PR supports those use cases.

What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?

I had four options:

1. Try to resolve the type of the module being imported, check whether it's an export = or an export default and pick the correct runtime representation for it.
2. Import the module during transpilation and test it to see if it has a default property. (This is the solution implemented in this PR.)
3. Curate a global list of modules that we know require default-import syntax (such as "ws").
4. Expose a configuration option to allow packages to locally specify whether a given module name should be treated as an export = or an export default.

I discarded solutions 1 and4. 1 is too expensive. 4 introduces too much complexity to the end-configuration of each package (the goal of the dev-tool sample transpiler is to make it simpler for package owners to maintain their samples).

Between 2 and 3, 3 was simpler, but I ultimately decided to implement 2 because it is a relatively simple, zero-configuration solution.

Are there test cases added in this PR? (If not, why?)

Yes. Additional file inputs and expectations have been added to test imports of @azure packages. I am currently investigating some options to properly test the main feature of testing the module shape.

[deyaaeldeen]

Looks good, thanks!

[maorleger]

🚀

[witemple-msft]

I'm not 100% sure how to go about testing the runtime-module testing, but this doesn't cause any new errors in the generation for form recognizer or text analytics. It does generate the correct require calls for purview and eventhub, even for the "ws" module that wasn't previously working. I'll continue thinking about how to automate testing that this works correctly other than relying on folks to report errors to me, but I don't want to delay this any further, so I'm going to go ahead and merge it.