Modules

Modules provide support for exporting and importing values without polluting the global namespace. We have had this capability in JavaScript through third-party libraries like AMD and CommonJS, but ECMAScript 6 now has this ability as well.

Note: This chapter deals with actual files to demonstrate export and import features of ECMAScript 6. All “file” references are to a file with the same name as the snippet title in the following format: code-listing-xxx.js.

Export

The best way of understanding export is by looking at it in action. Consider the following file:

Code Listing: 109

We are exporting a function named sum as well as a variable, pi.

Let’s move onto the next section and see how we can import.

Import

Now that we have created our own module, let’s take advantage and use it in our own code. Consider the following file:

Code Listing: 110

In this example, we are importing named exports from the module.

Code Listing: 111

As you can see, we were able to access both the function and the variable that we exported.

We can provide aliases for our named exports as well as our imports. Let’s look at another example:

Code Listing: 112

Here, we are exporting both sum and pi, but this time we have chosen to alias sum to add.

Let’s see how we use this in our file:

Code Listing: 113

As you can see, we are simply referencing the named exports, which includes the alias for sum.

How about we flip this around? Let’s look at the following file:

Code Listing: 114

Now let’s import this module as well as provide an alias in our file:

Code Listing: 115

This gives us a lot of flexibility when dealing with named exports. If we know that we already have a previous import that uses the same name, we can simply alias our import and avoid any type of conflicts. It is also possible to export another module inside your own after you have imported the other module.

Consider the following syntax:

Code Listing: 116

It will produce exactly the same output as well as export add and pi as named exports.

Default

When authoring your modules, you have the ability to define a default export. This allows you to perform a basic import and receive the default functionality. Let’s first look at what we need to do to our file:

Code Listing: 117

As you can see, the only difference here was that we added the default keyword to the first function.

Now, let’s look at the following file:

Code Listing: 118

If you know that you are only looking for the default export, this can be a handy feature. If you are authoring your own libraries and have a default export, this could become a nice, consistent feature. So even though we exported both sum and pi, all we had to do was name the reference sum and use it accordingly. The following is the output from running the preceding code:

Code Listing: 119

Note: You can only define one default export per module.

Wildcard

Wildcards allow us to load the entire module and refer to the named exports via property notation. Look at the following example:

Code Listing: 120

When we execute this code, we get the same result as the first import example:

Code Listing: 121

Some of you may be wondering: is it possible to access functions or variables when we load the entire module using the preceding syntax? Consider the following code:

Code Listing: 122

How about the notAvailable function? Let’s see what happens when we try to access it.

Code Listing: 123

This is what makes me really love modules! You have the ability to decide what you wish to expose to the outside and what you want kept internal to your module. Observe what happens when we try to run the preceding code:

Code Listing: 124

Now that is pretty slick. The module loader recognizes that you have not identified notAvailable as a function you wish to export and make public, and a scoping error is thrown the moment you try to run the code.

Module loaders

This section addresses loader handle resolving module specifiers (the string IDs at the end of import…from), loading modules, and the like. The constructor is Reflect.Loader. Each browser or transpiler that implements ECMAScript 6 modules keeps a customized instance in the global variable System (the system loader), which implements its specific style of module loading.

In addition to the declarative syntax for working with modules that we have been examining, there is also a programmatic API. It allows you to do the following:

Programmatically work with modules and scripts.

Configure module loading.

Importing modules and loading scripts

You can programmatically import a module via an API based on ES6 Promises, which we will be discussing in a later chapter. For now, consider the following:

Code Listing: 125

System.import() enables you to do the following:

• Use modules inside <script> tags where module syntax is not supported.
• Load modules conditionally.

System.import() retrieves a single module, but you can use Promise.all() to import several modules:

Code Listing: 126

We will cover how promises work in a later chapter.

More loader methods:

• System.module(source, [options]) – evaluates the JavaScript code in source to a module (which is delivered asynchronously via a promise).
• System.set(name, module) – is for registering a module (e.g. one you have created via System.module()).
• System.define(name, source, [options]) – both evaluates the module code in source and registers the result.

Configuring module loading

The module loader API has various hooks for configuration. It is still a work in progress.

The loader API will permit many customizations of the loading process. For example:

1. Lint modules on import, e.g., via JSLint or JSHint.
2. Automatically translate modules on import, even if the modules contain CoffeeScript or TypeScript code.
3. Use legacy modules like AMD and Node.js.

Configurable module loading is an area where Node.js and CommonJS are limited.