Today I will tell you about the export command and how you can create programs that consist of multiple files.

— Is there a limit on the length of one file in JavaScript?

— There may not be a limitation, but as the codebase of the program grows, the more important the structure becomes. Most projects are created by teams of programmers. If all development took place in one file, their life would be hell.

In the last lecture, we looked at constants. Very often there are situations when a constant needs to be used in several places. To make that happen and avoid code duplication, we usually create a separate file, for example, constants.js, initialize constants there, and export them for use in other project files.

//constants.js
export const NET_PROFIT_MARGIN = 10;
export const REGULAR_SALES_TAX = 25;

//solution.js
import { NET_PROFIT_MARGIN, REGULAR_SALES_TAX } from './constants.js';

console.log('Net profit margin is' + NET_PROFIT_MARGIN);
console.log('Regular sales tax is' + REGULAR_SALES_TAX);

In this example, we have declared and exported two constants from the file constants.js, and then imported and used them in the file solution.js.

There are 2 main rules you need to remember:

  • To export a constant, add the keyword export before the const.
  • To import a constant, you need to use the construction import { CONSTANT_NAME } from 'source_file_path', where CONSTANT_NAME is the name of the constant, and source_file_path is the path to the file where the constant was declared.

Please note that the path can be absolute or relative.

An absolute path starts at the root of the / filesystem on UNIX-like systems and is rarely used to import constants in javascript.

A relative path usually starts with . or .. and includes only part of an absolute path.

. - means that the file search should be started from the current directory

.. - the file search will start one directory higher than the current one

In our example, “seeing” the path to the file './constants.js', the computer will try to find the constants.js file in the same directory as the solution.js file. If we pretend for a second that the constants.js file is in the env directory, the path becomes ./env/constants.js.

If we assume that the solution.js file is located in the src folder, which is on the same level as the env folder, then we will need to “move” one level higher before starting the search and the path will change to ../env/constants.js.

— Sigma, levels are cool, but why aren’t you using camelCase?

— I’m glad you asked. Exported constants very often (but not always!) use the UPPERCASE with underscores rule to further emphasize that they are project-wide global. This rule coexists with the camelCase but is used for a different purpose.

The UPPERCASE with underscores rule is simple - write all words in capital letters, and separate them with an underscore.

If you are writing a game and want to create a constant that stores the “chance of rain” that’s global for all the game, then you can name your global constant as CHANCE_OF_RAIN.

Another thing that you won’t be able to live without in the big project is comments.

Commenting your code allows you to leave plain text messages that won’t be treated as code.

In JavaScript, there are 2 types of comments.

A single-line comment starts with a double slash. In the code snippets above, I’ve added the names of the files as comments in the very first line of those files.

The second type of comment is a multiline comment. It starts with the combo /* and ends with */.

Here’s an example of both.

//game.js - this line is not code. It's a single line comment.
import { CHANCE_OF_RAIN } from './constants.js';

/*
This
is 
a multiline
comment
*/
console.log(CHANCE_OF_RAIN);

If you’re curious, you can always learn more about comments in JavaScript here.