NodeJS’ Modules System & LCARS47’s New Framework

NodeJS’s Modules System

Nodejs has a very powerful framework in it that are called modules. I’d like to discuss how powerful this system makes a project. Throughout the development of a project, you may find yourself referencing all kinds of material. In JavaScript, it might be JSON files that store data, or libraries that handle API calls, or even promises that return mission-critical data from external sources. These are all core things that get handled by JS scripts that fall into one of these categories typically;

• Processed all in the script it is needed for
• Handled by libraries that also call other systems

These methods of requiring external data in JS quite literally uses the require method. require takes a path to a file and makes it available for later code to process. JSON files for example; when require is given the path to one and set to a variable, the properties and keys within that file become ready to be called by code and otherwise handled by functions.

Why is any of this being re-iterated? Because while require can do this, it can also require other parts of code or even whole scripts. You may have even made use of this functionality already by requiring other .js scripts.

Modules introduce the ability to export specific functions of code from a script using module.export. Take this example:

const { PI } = Math;

exports.area = (r) => PI * r ** 2;
exports.circumference = (r) => 2 * PI * r;

Local variables to the code are kept private, `PI` there for example. The next two lines are functions exported from this function to whatever calls it. See another, separate, code block:

const Square = require('./square.js');
const mySquare = new Square(2);
console.log(`The area of mySquare is ${mySquare.area()}`);

Squareis a class being created whose source is in ./square.js. The area is calculated using the same area function exported in the code block above.

As noted above, classes can be created and exported in the same means.

module.exports = class Square {
  constructor(width) {
    this.width = width;
  }

  area() {
    return this.width ** 2;
  }
};

Modules are implemented using the require('module')module.

All these ways to call code makes it very simple to execute code in a dynamic setup that can be…modularized. We’ll see this in action next.

*Kudos and code referenced from the Modules documentation via Nodejs.

LCARS47’s New Framework

As some of you may know (if you’re in CC, good chance you have no idea), LCARS47 has been offline and fairly neglected for a long time now. Fishsticks (LCARS47’s brother bot that is hosted for the CCG community) has been under far more active development for a good while now. Recently, it has been deemed worthy that given the advanced state of Fishsticks, and a lack of a utility bot for PlDyn, that the good ‘ole system watcher shall return.

The good news is that LCARS47 while making a return altogether, is getting a serious refactor. Most of the framework from before it went offline is now being redone to include a great deal more systems modularity than before. Some of you already know that the command handler that Fishsticks began using was devised under the experimental branch of LCARS47. Now, the development of Fishsticks Online (FSO) has brought new ways to store information and system variables across restarts. All of these new systems and implementations are being worked into LCARS47 through the means of various modules.

LCARS47 has always had scripts called “subroutines” that were just utility scripts that ran when needed off of a command. Now, the refactor includes far more utility scripts that will be in constant motion either communicating with LCARS47’s new database for member statistics records, system statistics upkeep, or just in general utility functions used across multiple commands. The core script of LCARS47 has greatly been reduced in complication thanks to the ability to properly shunt information to subsystem modules that will handle that information using their own subfunctions. This cleaner interface and referencing system allow for far better error management and command syntax failure interfacing (how LCARS47 will respond to the user when an incorrect or unknown parameter is given) along with much more.

So far, the refactor has given much more power to LCARS47 in terms of self-statistics and monitoring, dynamic list building such as help; each command carries its own help entry that can be dynamically updated when executed, and even functions for better time management handling, logging, and date handling.

I look forward to bringing more information to you about LCARS47’s new refactor and comeback.

Yeah, this is a copy pasta.
Original post available here.