export access modifiers

Search Terms

export access modifiers public protected private

Related: #321

Suggestion

Allow adding public, protected and private access modifiers to export statements. This would limit where the data can be imported from.

Access Modifiers

private

Other file in the same directory scope have access to the export.

protected

Other file in the same directory scope or a nested scope have access to the export.

public (default)

Current behavior - Can be access from anywhere.

Use Cases

Most useful for large projects - allows modules to limit where things they expose are used.

Examples

Given the following director structure:

.
├── module
│   ├── submodule
│   │   └── index.ts
│   ├── file.ts
│   └── index.ts
└── index.ts

// module/file.ts
public export const foo = "hello";
protected export const bar = "world";
private export const baz = "!!!";

// module/submodule/index.ts
import { foo, bar, baz } from '../file';
                // ^^^ Cannot access baz as is private.

// module/index.ts
import { foo, bar, baz } from './file'; // All Ok.

// index.ts
import { foo, bar, baz } from './module/file';
           // ^^^ Cannot access bar as is protected.
                // ^^^ Cannot access baz as is private.

Note: If using import * as X from ..., X's type simply wouldn't include things it doesn't have access to.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

首先查看相关 issue #321 以及此 issue 中的访问修饰符示例。在定位相关的 TypeScript 编译器测试之前，先定义应如何检查直接导入和 import * as 的目录访问及嵌套作用域访问。完成的标准是：提议的规则已明确规定并由测试覆盖，且不改变生成的 JavaScript。