@rbuckton I’m not sure what to do about this and the transpileModule tests, or if this is ok. I tried adding --moduleDetection force to the set of implicit transpileModule options and that broke a ton of stuff. I’m not sure what the rule is for when transpileModule produces module output, but it’s pretty odd to me that this does:

    transpilesCorrectly("Generates module output", `var x = 0;`, {
        options: { compilerOptions: { module: ts.ModuleKind.AMD } }
    });

when checking that file would clearly not consider it a module.

transpileModule expected all inputs are to be considered modules because isolatedModules expected all inputs to be modules. I think the issue for this test is that the new SourceFile we produce in the transform doesn't have an externalModuleIndicator, since we don't set that in the factory method, though we probably should.

... though we probably should.

This is a bit of a tricky problem. A file that starts as a Module, but might have its import/export declarations transformed out should probably stay a Module (since that's how we type-checked it, and how it was written). It's a bit more confusing when you have a file that may or may not have been a Module, but you add import/export syntax to it.

Right now, a Module stays a Module because we'll just copy the module indicator over verbatim. We don't really use that contents of that value in transforms, merely its truthiness. If we switch to updating that value, we have to take care that we don't set it to a falsy value (i.e., undefined) when the file was a Module to begin with, otherwise we might break consumers of the API.

I think most of these tests were written under the assumption that each file would be treated as a module by transpileModule. It may be fine to just amend the tests with an export {} to preserve this, since most of these tests weren't specifically testing that assumption, but some other mechanism instead.

I think the behavior I’ve implemented in this PR is better in some sense, but I worry about breaking people who were using our transpile API, but never using us to type check. Should we be concerned about that?

This is what I meant by this change affecting --importHelpers.

I think this is a correct change. The file is written as a script and checks as a script, so the output definitely can’t import the helpers, since that would make it lose its scriptiness.