Menu
TypeScript supports export = to model the traditional CommonJS and AMD workflow. The export = syntax specifies a single object that is exported from the module. This can be a class, interface, namespace, function, or enum.
Use named exports to export multiple classes in TypeScript, e.g. export class A {} and export class B {} . The exported classes can be imported by using a named import as import {A, B} from './another-file' . You can have as many named exports as necessary in a file.
Use a named export to export an interface in TypeScript, e.g. export interface Person{} . The exported interface can be imported by using a named import as import {Person} from './another-file' . You can have as many named exports as necessary in a single file.
TypeScript uses the concept of modules, in the same way that JavaScript does. In order to be able to import a type from a different file, it has to be exported using a named or default export.
The primary reason is that export matches the plans for ECMAScript. You could argue that "they should have used "export" instead of "public", but asides from "export/private/protected" being a poorly matched set of access modifiers, I believe there is a subtle difference between the two that explains this.
In TypeScript, marking a class member as public or private has no effect on the generated JavaScript. It is simply a design / compile time tool that you can use to stop your TypeScript code accessing things it shouldn't.
With the export keyword, the JavaScript adds a line to add the exported item to the module. In your example: here.SomeClass = SomeClass;.
So conceptually, visibility as controlled by public and private is just for tooling, whereas the export keyword changes the output.
A few things to add to Steve Fenton's answer:
export already means two different things (depending on whether it's at top-level or not); making it mean a third is probably worse than adding public/private
public vs export is trivial. We've changed keywords around a bunch already; it's not difficult.export (unexport??), so private is the logical choice. Once you have private, it would be somewhat insane to not choose public as its counterpartexport to modify visibility in internal modules is the best-guess alignment with ES6 modulesIf you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With