Helios Kernel - include in javascript, now for nodejs
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 moved to the githab , and the reason for the new release was the fact that the entire platform-specific code was allocated, and after some doping, I finally passed the tests under nodejs:
So now I can write here about the library the big word "cross-platform"
Determining dependencies with include () is the main feature of Helios Kernel. Other features naturally follow from it:
This is almost everything you need to know to manage dependencies in a project. The library was created with the idea that for a simple task, “the a.js module requires the b.js module to work.” You do not need to break your brain for example with such a manual.
Dynamic connection of modules in runtime is a different use compared to the description of dependencies. Therefore, Helios Kernel uses a separate function for this, kernel.require (), which loads the required modules and calls a callback. To disable modules, use the kernel.release () function. Thus, include () is not overloaded, and is used only to describe dependencies.
Proceeding from the simplicity, in the new version I tried to throw everything out of the library API, and left only include (), kernel.require () and kernel.release (). (Actually, kernel.release () also almost went under the knife).
“Exporting” library objects using global variables also simplifies the module structure. This method does not require anything from the Helios Kernel API. This allows, for example, to easily create the main library module that connects the rest. In this case, it is not necessary to “drag” parts of the library through the exported objects, and the main module will contain only the 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 manages the exported object.
Despite its ease of use, the module control system at Helios Kernel is quite flexible. The library keeps track of the modules requested by the user, and the additional code is loaded / unloaded based on the needs of various independent parts of the application. The state of each module is managed separately: when a module changes its state, dependent and dependent modules are notified of this, each of which decides what to do next. Therefore, when one part of the dependency tree is just loaded and parsed, the other can already be initialized and ready for use. All this happens transparently for the library user; he only needs to inform when it is necessary to load some new module or unload an unnecessary one. In addition, this approach allows you to track errors in the 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 in Helios Kernel works.
I will be glad to advice and comments (as well as to talk about conflicts and export through the global Osprey)
Project website: asvd.imtqy.com/helios-kernel
Download for free: 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 moved to the githab , and the reason for the new release was the fact that the entire platform-specific code was allocated, and after some doping, I finally passed the tests under nodejs:
So now I can write here about the library the big word "cross-platform"
Determining dependencies with 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 set to the exact file path, so it is 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.
This is almost everything you need to know to manage dependencies in a project. The library was created with the idea that for a simple task, “the a.js module requires the b.js module to work.” You do not need to break your brain for example with such a manual.
Dynamic connection of modules in runtime is a different use compared to the description of dependencies. Therefore, Helios Kernel uses a separate function for this, kernel.require (), which loads the required modules and calls a callback. To disable modules, use the kernel.release () function. Thus, include () is not overloaded, and is used only to describe dependencies.
Proceeding from the simplicity, in the new version I tried to throw everything out of the library API, and left only include (), kernel.require () and kernel.release (). (Actually, kernel.release () also almost went under the knife).
“Exporting” library objects using global variables also simplifies the module structure. This method does not require anything from the Helios Kernel API. This allows, for example, to easily create the main library module that connects the rest. In this case, it is not necessary to “drag” parts of the library through the exported objects, and the main module will contain only the 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 manages the exported object.
Despite its ease of use, the module control system at Helios Kernel is quite flexible. The library keeps track of the modules requested by the user, and the additional code is loaded / unloaded based on the needs of various independent parts of the application. The state of each module is managed separately: when a module changes its state, dependent and dependent modules are notified of this, each of which decides what to do next. Therefore, when one part of the dependency tree is just loaded and parsed, the other can already be initialized and ready for use. All this happens transparently for the library user; he only needs to inform when it is necessary to load some new module or unload an unnecessary one. In addition, this approach allows you to track errors in the 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 in Helios Kernel works.
I will be glad to advice and comments (as well as to talk about conflicts and export through the global Osprey)
Project website: asvd.imtqy.com/helios-kernel
Download for free: github.com/asvd/helios-kernel/releases/download/v0.9.5/helios-kernel-0.9.5.tar.gz
Watch online: github.com/asvd/helios-kernel
Source: https://habr.com/ru/post/198964/
All Articles