CabloyJS builds and publishes modules based on EggJS implementations

background

EggJS is now adopted by many development teams. The question that some teams ask for commercial intellectual property is: Can you compile and package the code in EggJS and then ugly it?

Mechanism for module compilation

• EggJSWhy can’t it be done convenientlycompileThe feature?

In EggJS, code files are organized and loaded by convention code locations. That is, the code files are placed in the convention directory structure, and EggJS scans and loads the convention code files at the convention location when it starts the system. Therefore, compilation features cannot be easily implemented under this mechanism

• CabloyJSHow is the compilation feature implemented?

EggJS provides enough flexibility as an enterprise-level framework, for example, to allow the upper framework to provide custom loaders. CabloyJS implements a set of custom loaders based on EggJS

In CabloyJS, code files in modules are explicitly organized and loaded by require. This loading mechanism provides a clear call dependency for the source file inside the module, so we can use Webpack to complete compilation packaging, and ugly code work

The significance of module compilation

1. Module reuse and ecological construction: Modules can be compiled separately, so that they can be published separately, deployed separately and upgraded separately, thus promoting the prosperity of CabloyJS ecosystem and further accelerating the development of actual business
2. Intellectual property rights: Modules can be compiled separately or can be satisfiedProtecting business codeThe demand of

How to compile modules

Go to the directory where the module resides
$ cd /path/to/module
Compile module front-end code
$ npm run build:front
Compile the back-end code of the module
$ npm run build:backend
Copy the code

Compile parameters

All modules use the default build parameters, but you can also provide custom build parameters, such as module test-party:

src/module/test-party/build/config.js

module.exports = {
  front: {
    productionSourceMap: false.uglify: true,},backend: {
    productionSourceMap: false.uglify: true,}};Copy the code

Module loading convention

In the module directory, you have both the SRC source file and the dist package file. So when do YOU load SRC and when do you load dist?

There are two types of modules: global and local. The two types of modules have different loading conventions:

1. Global module: Located in the projectnode_modulesDirectory, the system always loadsGlobal modulethedistThe packaged file
2. Local module: Located in the projectsrc/moduleThe system searches the directory firstsrcDirectory and load the module source code, if it is not foundLocal modulethedistThe packaged file

Understanding the code loading conventions of global and local modules helps to make the right configuration when deploying the project to production (the main appeal is: how to protect commercial code)

Best Practices (module front end)

At deployment time, the project front end is always compiled in its entirety, packaging front-end source code and front-end resources for all global and local modules and exporting them to the project dist directory

If a module exists as a local module, you don’t need to worry about the compilation at the front of the module

If a module is to be published as a global module, the module front end must be compiled first

Best Practices (module back end)

1. Do not compile modules

If there is no need to protect commercial code, then module compilation is not a concern. At deployment time, simply load the source code and run it as a local module

2. Compile the module

If you want to do module compilation, there are two options at deployment:

• As a local module
  1. The module is still located in the projectsrc/moduledirectory
  2. After compiling the module, delete the module in the production environmentsrcSource directory
• As a global module
  1. Compile the module and publish it to the company’s private repository
  2. Treat the module as a projectGlobal moduleThe installation tonode_modulesdirectory
  3. If you don’t have a private warehouse, you can use itnpm linkMechanism installation isGlobal module

Module to release

When the module code in the project is stable, the module can be published and contributed to the open source community. It is also possible to set up a private NPM repository within the company and then publish the modules to a private repository to form corporate assets for easy reuse

$ cd /path/to/module
$ npm run build:front
$ npm run build:backend
$ npm publish
Copy the code

Because modules published to the NPM repository will be used as global modules, the front and back ends of the modules need to be compiled first

Renderings (module back-end compilation)

Source code structure before compilation

The compiled output file

A link to the

• Website: https://cabloy.com/
• GitHub: https://github.com/zhennann/cabloy