Namespace support

[saschatimme]

As a library author it would be beneficial to not expose internal modules. Currently the schema supports the public attribute but this yields to the following behaviour:

We have a file reactNative.re with content

module View = ViewRe;
module Style = StyleRe;

and a bsconfig.json with

{
   .....
    "sources": [{
        "dir": "src",
        "subdirs": {
            "dir": "components",
            "public": "none"
        },
        "public": ["ReactNative"]
    }]
}

Now the only exposed module is ReactNative and View is accessible but not the content of View, e.g. View.createElement`.

Expected behaviour

If a module is declared public all its submodules are public as well.

[bobzhang]

the current work around is list ViewRe and StyleRe public too

[bordoley]

@bobzhang Are there technical reasons that submodules, and modules returned by functors are implemented as arrays as opposed to JS objects?

[bobzhang]

Is this question relevant to this issue? Implement as arrays are easiest to do, we may improve it for debugging purpose, but in general you should not rely on the underlying representation except global modules reply@reply.github.com At: 05/10/17 18:46:46" data-digest="From: reply@reply.github.com At: 05/10/17 18:46:46" style=""> From: reply@reply.github.com At: 05/10/17 18:46:46 To: bucklescript@noreply.github.com Cc: Hongbo Zhang (BLOOMBERG/ 731 LEX), mention@noreply.github.com Subject: Re: [bloomberg/bucklescript] Namespace support (#1584) @bobzhang Are there technical reasons that submodules, and modules returned by functors are implemented as arrays as opposed to JS objects? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bordoley]

@bobzhang: Yes tangentially for interop with js. Toplevel module as a namespace works well, but is practically hard to use when exposing code to javascript.

[bobzhang]

done in last release