Repository: TypeScript
Issue: Add compiler option to allow module types to be checked in non module output files
Labels: Suggestion,In Discussion

**Search Terms:** `import type`, `export {}`

## Suggestion

In #41513 and #41562  projects are broken by a design change to always include `export {};` in the JS output if `import` or `import type` is in the TS source, regardless of whether it is in the JS output. This is a breaking change for a lot of developers and painful to fix (and by fix I mean practically get the output of our TS project to run in browsers, not necessarily adhere to ECMA spec compliance and best possible practice).

However, `export {};` considered desirable:

> You're free to suggest a new compiler option but this is the intentional behavior.
> _Originally posted by @RyanCavanaugh in https://github.com/microsoft/TypeScript/issues/41513#issuecomment-727057724_

Please could we have a new compiler option to not force all files that in any way use ES modules to always have to include `export {};` in the JS output. 

I'm not sure of the best way for this to be applied, but the goal would be
- Type checking compatible with an ESM project.
- Output compatible with the current state of module support in browsers.

This could be:
- A compiler option that causes `import type` to not implicitly convert output to a module, (my preference because it still avoids any output JS having `import` without `export`, which caused #38696) or 
- A compiler option to not add `export {};` to _all_ modules, or 
- A `//@directive` we add to a file to express our intent to not output a module, or
- A new `reference type ...` TS-only syntax to signal that we want to use the definition but not output a module 

Whatever is easiest to code and causes least friction/confusion for the community.

## Use Cases

I have a large TS project that uses numerous web workers, a service worker and web components that load side effects.

In the first two cases including `export {};` breaks the resulting JS, as these workers are not modules and are not intended to produce module loaded JS output.

In the case of side effect web components no `export` is expected (they use `customElements.define`) so it's just wasted bytes, but it doesn't break anything. Across a project with a lot of components the many `export {};` that will never be referenced by anything adds up.

In addition during migration between different reference types it may be extremely beneficial to not strictly enforce adherence to one type or the other, at least while not in production. Any modules = all must be modules effectively makes this migration harder, even if it is a sound best practice.

## Examples

I have a model `MyModel.d.ts`. 

In `worker.ts` I want TS to check my code against this model:

```ts
import type MyModel from './MyModel';
const test: MyModel = {};
test.propertyInModel = 1; // works and has intellisense
// test.propertyNotInModel = 1; throws compile error!
```

I want to use the JS output this with a worker in another file:

```ts
const worker = new Worker('path/worker.js');
```

This worked in 3.8, but fails in 4.0 due to #41562

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code (it would fix a lot of projects broken by 4.0)
* [x] This wouldn't change the runtime behaviour of existing JavaScript code (it would be opt-in)
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.) (we're removing additional content that wasn't in 3.8)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals). (particularly 4, 7 and 11)