Always Emit export {}

#38696

• What does "always" mean?
• If there were import/export statements in the file, there must at least be one import or export in the output.
• We already have this rule in declaration files.
  • We just don't do it in module output.
  • We probably do.
• This is valuable for tools like Webpack/TypeScript, but there's a class of users who won't want this.
  • They will have a point.
• Conclusion
  • Add the export {}.
  • Do we need a patch release?
    • Sounds like no.
  • Preserve module marker in es2015+ module emit for tool compatibility #38712

Optimization hints on classes

#38602
#38566

In 3.9 we started emitting an IIFE around classes with statics when targeting ES2015.

class C {
    static x = someExpression();
}

Becomes

let C = /** @class */ (() => {
    class C {
    }
    C.x = someExpression();
});

Closure can't understand this output.

https://www.hyrumslaw.com/

• Why are we emitting the noise anywhere?
  • Design Meeting Notes, 6/2/2017 #16414
  • Exacerbated by Wrap classes with decorators or static properties in an IIFE, even for ES2015+ #32011
• Shouldn't classes be used? Sounds like it should've been a dead-code elimination problem.
  • Bundlers not always good at tree-shaking.
• Want to give the option, but maybe the default should be nice output.
• Conclusion: ask more about the current issues, understand the problem better.

Allow modules to implement interfaces

#420

• What about contextual typing and inference on the members?
  • We already have that on values in general, don't co-mingle that.
  • Operator to ensure an expression is contextually typed by, and satisfies, some type #7481
• What about being able to validate that types are present?
  • Now you need to have meta-typed module system.
• Most people seem to just want to validate the types.
• What are the wins?
  • React Native platform-specific modules.
  • Config files
    • Allow a module to implement an interface #420 (comment)
    • .eslintrc.js does not have suggestions vscode-eslint#124
    • Needs JSDoc support then.
  • Plugin Systems
  • Mocking in Tests
• Maybe the syntax might differ depending on module type.
• Could imagine there's just a design-time check for type compatibility.
  • Assert a value or type conforms to some other type.
• Problems
  • The syntax space isn't fleshed out
  • There's a lot of adjacent proposals
  • There's no way to make this check things other than modules.