Javascript multiple files best practices

I've been branching out from the freecodecamp curriculum and looking at random games that people have posted online (github, codesandbox.io, etc) and have seen various ways that people link multiple .js files together and thought about what the preferred way this is done in the industry so I don't pick up any bad habits.

Some people break down all the various functions they need in multiple files and then link them on the HTML file with something like , which seems to be the easiest though not the neatest method and without discipline, it's easy to make them too long. I also found out doesn't work on codesandbox.io and results in a bunch of errors because it can't find what was declared on the other files and requires using imports and exports.

Other people I've seen take the approach of having just one main index.js file that goes in the HTML and the index.js file will then import all the other javascript files it needs. On bigger projects I see that index.js only imports a main.js which then imports all the various .js files (which have just a single class in them) that are used in the project.

So which style is preferred and I'm sure I'm leaving out other ways people do things so please let me know how you or your company do things and why. Just from my view, it seems having just one point of entry makes things a lot neater and lets you reuse the classes later for other things too.

JavaScript is an easy to learn programming language. It’s easy to write programs that run and does something. However, it’s hard to account for all the uses cases and write robust JavaScript code.

In this article, we’ll look at how to name our files and proper encoding for our files.

Also, we look at the right way to deal with modules.

File Names

File names should be all lower case and may include underscores or dashes.

We shouldn’t put any additional punctuation in our file names.

The file names should end in .js so that we know that it’s a JavaScript file.

For instance, foo.js is a good file name.

File Encoding

The encoding of the file should be UTF-8. This is standard across all platforms so that it won’t cause issues when we run them anywhere.

White Space Characters

The ASCII horizontal whitespace character should be the only one in source files.

Other whitespace characters should be escaped.

Tabs shouldn’t be used for indentation since they may be interpreted differently in different platforms.

However, tabs can be converted to spaces automatically.

Special Escape Sequences

Special escape sequences should have a corresponding numeric escape.

So \' is the same as \x27 , for example.

Non-ASCII Characters

We should use Unicode equivalent for non-ASCII characters in our code files.

Source File Structure

We may want to enforce some structure in our source files.

For instance, we may have JSDoc comments for documentation.

We may put them in folders so that there’s a clear hierarchy in our project structure.

ES Modules

Modules are used in most new JavaScript projects now.

Therefore, we should be mindful of some rules regarding modules.

Import Length

Length of import statements should be 100 characters or less so they won’t overflow the screen.

This way, no one has to scroll horizontally to read the whole line.

Import Paths

We should use the import sattement to import ES modules.

For instance, we can write:

import './foo';

or:

import * as foo from './foo.js';

or:

import { name } from './foo.js';

We don’t need the extension when importing files.

Importing the Same File Multiple Times

We shouldn’t import multiple members of the same file in different import statements.

For instance, instead of writing:

import { bar } from './foo';
import { baz } from './foo';

We write:

import { bar, baz } from './foo';

Naming Imports

We can name imports with the as keyword.

The name should be camelCase.

For instance, we write:

import * as fooBar from './fooBar';

Naming Default Imports

We can name default imports with camelCase also.

For instance, we can write:

import fooBar from './fooBar';

Naming Named Imports

Also, we can change the name of named imports so that we can use the name that we want to use.

For instance, we can write:

import { Cat as FatCat } from './animal';

for constructor imports or:

import { cat as fatCat } from './animal';

for other imports.

Named vs Default Exports

We can have named and default exports just like imports.

For instance, we can create a default export by writing:

export class Foo { ... }

and a named export by writing:

export { Foo }

Export Container Classes and Objects

We shouldn’t export container classes and objects

Therefore, instead of writing the following:

export class Container {
  static foo() {
    return 1;
  }
}

We write:

export function foo() {
  return 1;
}
export const FOO = 1;

Mutability of Exports

Don’t export variables that are mutable.

This means anything declared with let shouldn’t be exported.

For instance, instead of writing:

export let foo = 1;

We write:

export const foo = 1;

export from Statements

We should wrap export from statements so that it stays within 100 characters per line.

So we write:

export * from './foo';

or:

export { bar } from './another.js';

Circular Dependencies in ES modules

We shouldn't create circular dependencies between ES6 modules, directly or indirectly.

For instance, we shouldn’t write:

b.js :

import './a';

and:

a.js

import './b';

Conclusion

We should be careful when working with file names and modules.

File names should be named in lowercase with underscore or dashes,

We should use modules and they shouldn’t have circular dependencies.

Code files should be UTF-8 encoded to avoid issues running them.

Is it good to have multiple JS files?

How do I include multiple JavaScript files?

Should all my JavaScript be in one file?

How do you organize JavaScript files?