Consider adding a module level visibility modifier.

[zpdDG4gta8XKpMCd]

Currently to protect integrity of data one can only use classes with private or protected fields. Classes are harder to work with compared to object literals. Being able to specify that certain fields are invisible to outside modules would be a valuable addition to support programming in functional style in TypeScript.

So what I am suggesting is to be able to specify whether a field of an interface is exported from a module or not. This also means that the instance of such interface can only be created within the module it is declared.

The similar features can be found in:

• F# called signature files: http://msdn.microsoft.com/en-us/library/dd233196.aspx
• Haskell called export lists: http://www.haskell.org/onlinereport/modules.html

[sophiajt]

Would be good to see the motivating examples behind this and what JavaScript patterns this would help enable. Some general tips for proposals: https://github.com/Microsoft/TypeScript/wiki/Writing-Good-Design-Proposals

[zpdDG4gta8XKpMCd]

I hear your call for more formal proposal. I will try my best as soon as I have time for it. Meanwhile here is an example. I want to get a lightweight implementation of a doubly linked list in TypeScript. The most lightweight version as far as I can see would be based on object literal rather than classes. It would look something like this:

// module: DoublyLinkedList

export interface Node<a> {
    /* module */ left: Node<a>;
    value: a;
    /* module */ right: Node<a>;
}
export interface List<a> {
    /* module */ left: Node<a>;
    /* module */ right: Node<a>;
}
function createNode<a>(left: Node<a>, value: a, right: Node<a>) {
    var node = { left: left, value: value, right: right };
    if (left != null) { left.right = node; }
    if (right != null) { right.left = node; }
    return node;
}
export function createEmptyList<a>() : List<a> {
    return { left: null, right: null }
}
export function createList<a>(value: a): List<a> {
    var node = createNode(null, value, null);
    return { left: node, right: node };
}
export function addRight<a>(list: List<a>, value: a) : Node<a> {
    return createNode(list.left, value, null);
}
export function addLeft<a>(list: List<a>, value: a) : List<a> {
    return createNode(null, value, list.right);
}
// many other functions to manipulate a double linked list
export function isLast(node: Node<a>) { 
    return node.right == null;
}

Now notice that the internal properties like left and right of the List and Node interfaces are exposed. These properties are not supposed to be seen. But there is no way to hide them unless we switch from lightweight object literals to instances of classes and use private modifier. So clearly the internals of the list and node are vulnerable to unintended or deliberate changes that we wish we could prevent to maintain the integrity.

Notice the \* module *\ comments in the Node and List interfaces. This is what I wish the module visibility modifiers looked like. There is no need to introduce another keyword, as we reuse some already existing one.

[RyanCavanaugh]

You can emulate this somewhat simply today:

module Impl {
    interface Node<a> extends Public.Node<a> {
        left: Node<a>;
        right: Node<a>;
    }
    interface List<a> extends Public.List<a> {
        left: Node<a>;
        right: Node<a>;
    }
    export function createNode<a>(left: Node<a>, value: a, right: Node<a>) {
        var node = { left: left, value: value, right: right };
        if (left != null) { left.right = node; }
        if (right != null) { right.left = node; }
        return node;
    }
    export function createEmptyList<a>() : List<a> {
        return { left: null, right: null }
    }
}
module Public {
    export interface Node<a> {
        value: a;
     }
     export interface List<a> {
         /* empty */
     }

    export var createNode: <a>(left: Node<a>, value: a, right: Node<a>) => Node<a> = Impl.createNode; 
    export var createEmptyList: <a>() => List<a> = Impl.createEmptyList; 
}

export = Public;

One big advantage here is that the Public module can be an exact carve-out of Impl's functionality depending on exactly what you want to do.

[zpdDG4gta8XKpMCd]

Such emulation solves only one half of the problem by hiding the internals. In your example the Public instances of both List and Node interfaces can be created outside of the module. Such instances are no use, because the integrity is violated when an instance from Public is used instead of an instance from Impl. I mean from the Public stand point hidden fields === absent fields whereas Impl calls for the hidden fields to be present.

[zpdDG4gta8XKpMCd]

@mhegazy, @DanielRosenwasser, @RyanCavanaugh

guys, is this @internal marker official?

[mhegazy]

guys, is this @internal marker official?

no, it is an internal "hack", that we can remove with no warning. we are looking for ways to make this scenario supported. so stay tuned.

[SalihKARAHAN]

👍 we need it 😊

[mhegazy]

related: #5228

[gitowiec]

How is work in progress with it? Or is there any work around? I wanted to use Namespaces but I can't because ///<reference path="./anyFileName.ts"/> does not work if there are imports in anyFileName.ts :(
I would like to achieve private package members, but exportable to allow file splitting inside of package.

[jonaskello]

I just found that flow now actually supports opaque types aliases which from what I understand is very similar to my suggestions in #15408 and #15465.

[lorenzodallavecchia]

A related case that I stumble upon quite often is when I want to provide a base class for extension and that class contains members that are only used for collaborating with other code inside the module.

// module utils.ts

export abstract class Base {
  exposedA() { };
  protected exposedB(): { };
  /* module */ modulePrivate(): { };
}

// other code that calls Base.modulePrivate

Currently, I have no way to do the above without enabling access to modulePrivate from other modules.

import { Base } from "./utils";

class Derived extends Base {
}

// here the internal details of the module are exposed via Derived.modulePrivate

The crucial point here is that I want to enable the extension of a class. In cases where I don't want others to extend I just implement the class internally (without export) and export an interface instead.