This project is read-only.

Intended usages of ambient internal modules

Topics: Language Specification
Sep 25, 2013 at 7:12 AM
I have two questions about modules:
  1. Could the difference between external vs internal modules more accurately be described as implicit vs explicit modules?
  2. What is the intended use case of ambient internal modules. Most of the time you want to define ambient external modules so they can be imported. What would be the case where you want to define a module to be used without importing it?
Sep 26, 2013 at 12:20 AM
Ambient vs non-ambient and external vs internal are really two independent things.

You use ambient declarations when you're simply describing existing values and types without implementing them in that compilation unit. Ambient declarations can describe internal modules, external modules, classes, vars, etc.

Internal modules are for organizing types and values into namespaces, optionally using the true privacy provided by the closure module pattern. You can use an internal module inside an external module to further organize your code.

External modules are for use in loader systems like those used in RequireJS or node. If you want to use a module loader, you'll write code in an external module. If you're just loading your JS straight through a script tag, you won't.
Sep 26, 2013 at 11:12 AM
Yes, the meaning of ambient is quite clear to me. I was just trying to understand external and internal and wondered whether they could be thought of as simply explicit and implicit modules or if there is something else to them that is not captured by those descriptions.

So you would use ambient internal modules mostly for simple client side code and ambient external modules for the rest?

I thought there was also something about not being able to extend members of ambient internal modules.