Helios Kernel - include in javascript, now for nodejs too
Hello World,
Helios Kernel is a library that allows you to describe dependencies between javascript modules “in the style of include”:
I already wrote about Helios Kernel before , since then the project has moved to github , and the reason for the new release was the fact that the whole platform-specific code was allocated, and after some completion

I finally updated the tests for nodejs too: So now I can write here about the library the big word "cross-platform"
Defining dependencies using include () is the main feature of Helios Kernel. Other features naturally follow from it:
That's almost all you need to know to manage dependencies in a project. The library was created with the thought that for the simple task “the a.js module requires the b.js module to work”, you do not need to break your brain with such a manual, for example .

Dynamic connection of modules in runtime is a different user case compared to the description of dependencies. Therefore, Helios Kernel uses a separate function for this, kernel.require (), which will load the required modules and call the callback. To disable modules, use the kernel.release () function. Therefore, include () is not overloaded, and is used only to describe dependencies.
Based on simplicity, in the new version I tried to throw out everything that is possible from the library API and left only include (), kernel.require () and kernel.release (). (In fact, kernel.release () also almost went under the knife).
“Exporting” library objects using global variables also simplifies the structure of the module. This method does not require anything from the Helios Kernel API. This makes it possible, for example, to easily create a main library module that connects the rest. In this case, it is not necessary to “drag” parts of the library through exported objects, and the main module will contain only a list of inclusions. It will also simplify documentation and use - each library object will always be named the same, and will not depend on how the user disposes of the exported object.
Despite the ease of use, the module management system in Helios Kernel is quite flexible. The library keeps track of the modules requested by the user, and additional code is loaded / unloaded based on the needs of various independent parts of the application. The state management of each module is carried out separately: when a module changes its state, dependent and dependent modules are notified about this, each of which decides what to do next. Therefore, when one part of the dependency tree is just loading and parsing, the other can already be initialized and ready for use. All this happens transparently for the library user, he only needs to be informed when he needs to load some new module or unload the unnecessary one. Moreover, this approach allows you to track errors in loading / initialization of modules, and, for example, cyclic dependencies. In such cases, errors will be displayed in the console, but the application will continue to work normally, and the broken and dependent modules will be correctly unloaded.
I'm also going to write a separate post describing how module management works in Helios Kernel.
I will be glad to advice and comments (as well as praise on the topic of collisions and exports through the global osprey)
Project site: asvd.github.io/helios-kernel
Free download: github.com/asvd/helios-kernel/releases/download/v0.9.5 /helios-kernel-0.9.5.tar.gz
Watch online: github.com/asvd/helios-kernel
Helios Kernel is a library that allows you to describe dependencies between javascript modules “in the style of include”:
// объявление зависимостей
include("path/to/library1.js");
include("../path/to/another/library2.js");
init = function() {
// использование зависимостей
library1.doSomething();
...
}
I already wrote about Helios Kernel before , since then the project has moved to github , and the reason for the new release was the fact that the whole platform-specific code was allocated, and after some completion

I finally updated the tests for nodejs too: So now I can write here about the library the big word "cross-platform"
Defining dependencies using include () is the main feature of Helios Kernel. Other features naturally follow from it:
- Dependencies are defined in the module header (not in the module body, not in external configs)
- Dependencies are specified by the exact path to the file, so it’s always easy to understand where they are located
- The "export" of objects created by the module is carried out through the definition of global variables. This approach simplifies the description of the module and its use, since there is no need to declare a special exported object and reuse it.
That's almost all you need to know to manage dependencies in a project. The library was created with the thought that for the simple task “the a.js module requires the b.js module to work”, you do not need to break your brain with such a manual, for example .

Dynamic connection of modules in runtime is a different user case compared to the description of dependencies. Therefore, Helios Kernel uses a separate function for this, kernel.require (), which will load the required modules and call the callback. To disable modules, use the kernel.release () function. Therefore, include () is not overloaded, and is used only to describe dependencies.
Based on simplicity, in the new version I tried to throw out everything that is possible from the library API and left only include (), kernel.require () and kernel.release (). (In fact, kernel.release () also almost went under the knife).
“Exporting” library objects using global variables also simplifies the structure of the module. This method does not require anything from the Helios Kernel API. This makes it possible, for example, to easily create a main library module that connects the rest. In this case, it is not necessary to “drag” parts of the library through exported objects, and the main module will contain only a list of inclusions. It will also simplify documentation and use - each library object will always be named the same, and will not depend on how the user disposes of the exported object.
Despite the ease of use, the module management system in Helios Kernel is quite flexible. The library keeps track of the modules requested by the user, and additional code is loaded / unloaded based on the needs of various independent parts of the application. The state management of each module is carried out separately: when a module changes its state, dependent and dependent modules are notified about this, each of which decides what to do next. Therefore, when one part of the dependency tree is just loading and parsing, the other can already be initialized and ready for use. All this happens transparently for the library user, he only needs to be informed when he needs to load some new module or unload the unnecessary one. Moreover, this approach allows you to track errors in loading / initialization of modules, and, for example, cyclic dependencies. In such cases, errors will be displayed in the console, but the application will continue to work normally, and the broken and dependent modules will be correctly unloaded.
I'm also going to write a separate post describing how module management works in Helios Kernel.
I will be glad to advice and comments (as well as praise on the topic of collisions and exports through the global osprey)
Project site: asvd.github.io/helios-kernel
Free download: github.com/asvd/helios-kernel/releases/download/v0.9.5 /helios-kernel-0.9.5.tar.gz
Watch online: github.com/asvd/helios-kernel