How to keep your frontend application code under control

#javascript #webdev #tutorial

When you develop a complex frontend application its code may become confusing and hard to understand. Simply because most of the time you don’t have time to write “clean” code and document everything you write. Even if you work in a big team with well-established development processes it’s sometimes hard to get in touch with some parts of an application. Especially for newer developers.

Usually splitting your code by modules can solve this problem. Purely modules are just isolated parts of code which are used in different places of your project. For example, if you develop a react application you might have modules which contains its related components, utils, tests, store, router, etc. It is a lot simpler to deal with a such structured code.

But even with that kind of a project structure, it is not always obvious how these modules interact with each other. For example, if you want to refactor one module you might not be fully sure to which modules your changes would affect.

How to simplify working with modules?

You can write small descriptions for every module you have. And where they are used in the project. The problem is that it is very difficult to keep this information up to date.

I decided to create a tool that will collect and show the information about application modules. Modulism is a CLI for keeping track of how modules depend on each other in your project. It allows you to see where the module is used and what other modules it imports by one command.

Modulism CLI main feature

CLI collects data about imports in all files of your project and based on this builds a graph of module dependencies from each other which is saved in the configuration file. After this process is done you are able to get information about any module in your project by running modulism log <ModuleName> command in your terminal.

You can also print out information about every module by running modulism log (without specifying modules).

This could help you with:

Detection of unnecessary imported functionality.
Checking which modules may be broken by refactoring a certain one.
Figuring out a module or modules you do not know anything about.

Example of a printed module information:

"Imports" is the list of modules selected module is importing to itself. Blue dots are certain groups of modules that are being imported.
"Exports" are modules to which selected module is being exported. Purple dots are groups of selected module which it is exporting.
"Groups" are certain parts of selected module's code.

How does the CLI determine which module is located where?

In order to get started, you must label your modules. To do this, create a <moduleName>.modulism file in the module's root folder.

<moduleName>.modulism file could be empty or has module's description in it.

You can also split your modules by groups so the result data would be more informative for you.

You can do it in two ways.

Determine group directory. To determine group directory just add .<groupName>.modulism file in your group directory.
Determine group file. To determine group file add *modulism-group <groupName> line in comments of your file.

Example directory of a module with two groups (constants and logic):