4.4 Running namespace & legacy internal modules

In this recipe we will learn about the different ways in which a library or application build with namespace (or legacy internal modules).

Getting Ready

All you need to implement in this recipe is an installation of TypeScript version 2.0 or higher.

How to do it

The library included in the companion source code declares a library called ndrscr.

Note that the ndrscr module is named ndrscr_with_namespaces in the namespaces sample included in the companion source code to avoid conflicts with the example that uses legacy internal modules (ndrscr_with_internal_modules).

This library is implemented using namespaces under the following directory: /chapter_03/src/module_definitions/design_time/internal/namespaces To load the JavaScript code generated for some namespaces you must:

  • Compile each of the files that declare the namespaces
  • Create a html file and
  • Load each of the resulting JavaScript file using a script tag:
<script src="arrays.js"></script>
<script src="collections.js"></script>
<script src="functions.js"></script>
<script src="objects.js"></script>
<script src="utility.js"></script>
<script src="ndrscr.js"></script>

How it works

Loading namespaces or legacy internal modules in a web browser is really simple. All we need to do is to use a script tag to load the contents of the files which declare the namespaces. Namespaces and legacy internal modules are good way to do a quick test of some concept or idea but they can lead to some problems.

  • The first problem is that it is hard to prevent this kind of modules from creating variables in the global scope (which is considered a bad practice by the TypeScript and JavaScript development communities).
  • The second problem is that we used many script tags to load the library and this will have a negative effect in our application’s performance.
  • The third problem is that we will not be able to load internal modules in a Node.js application because Node.js was designed to work with CommonJS modules and not global variables. We could solve these problems using some external tools but that would lead us to do some extra work that could be avoided by using external modules. For above reasons you should try to use external modules when possible instead of internal modules.

There’s more

It is possible to use the TypeScript compiler to generate one single file which contains all the modules in the application. The following gulp tasks showcases how to do it:

gulp.task('build-namespaces', function () {
    const tsProject = ts.createProject('tsconfig.json', {
        typescript: require('typescript'),
        'out': 'bundle.js'
    const input = './src/module_definitions/design_time/internal/namespaces/*.ts';
    const output = './src/module_definitions/run_time/internal/namespaces/';

    return gulp.src(input)

The compiler options are set in the tsconfig.json file but we have set the most important compiler option for this example in the gulp configuration file. The out options is used to indicate the name of the file that will contain all the modules. As a result, we will be able to load all our namespaces with one single script tag:

<script src="bundle.js"></script>
Please note that this example is included in the companion source code.

Source Code

Running namespace & legacy internal modules

See also

Please refer to the preceding recipes in this chapter about namespaces to learn how to declare and consume this kind of modules.

Shiv Kushwaha