Fix source type detection when parsing TypeScript

[JLHwung]

Q	A
Fixed Issues?	parsing export { a } with typescript plugin and unambiguous source type does not set program sourceType to module (part of #16679)
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

This issue surfaces when we are aligning to the typescript-eslint AST. The typescript parser plugin called super.parseExport without handling the sawUnambiguousESM state, here we moved the state handling into parseExport so it should work for both JS and TS.

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/58671

[JLHwung]

Here is one thing typescript-eslint differs: they set the sourceType to module even when the source only includes type imports/exports: AFAIK TS does not offer ways to include types via commonJS require, so I am not convinced that we should do so as well. To align with their AST we can monkey patch the eslint-parser instead.

@bradzacher Could you shred some light here? Thank you.

[bradzacher]

It's actually entirely correct to treat the file as a module if it only contains only type-only import -- it's the same behaviour that TS itself exhibits.

For example you can see in this playground.

1. the emitted JS code is export {};
2. there is no error on the Map interface (see below)

But if you comment out the type-only import then:

1. the emitted JS code is instead "use strict"; as it's no longer treated as an ESM file
2. there is an error on the Map interface as TS is trying to declaration merge with the global type.

So yeah -- our behaviour is aligned with TS itself.

[bradzacher]

AFAIK TS does not offer ways to include types via commonJS require

It does, but not in the same "type only" fashion.

// module.ts
namespace Foo {
  export type T = number;
}
export = Foo;

// other.ts
import Foo = require('./module');

type T = Foo.T;

It's much more cumbersome, but still valid.

[JLHwung]

@bradzacher Thank you for your detailed explanation, from which I have learned a lot. In that case I think we will align to TS as well.

[JLHwung]

This PR also changes the flow handling. As we can see from the playground, both

import react from "react";
const yield = 1;

and

import type react from "react";
const yield = 1;

are accepted, which means flow does not set the script type based on imports. So we already deviated from the flow behaviour for non-type imports.