01 What is konos
Now the definition of the front-end framework is becoming more and more extensive, and a specific solution in a certain link in the front-end engineering can be generally referred to as a front-end framework.
Konos is a plug-in front-end framework base. If you know umi, you can use it as a umi core base without any functions.
Konos provides some simple interfaces for users to expand and write cli services.
For example, if you want to write a 'yarn create app' to initialize the project, you only need to:
Then execute 'npx konos init cli' to complete a job of generating scaffolding after interacting with the user.
02 Why there are konos
This requirement originally came from the requirements of the Lingbee framework of the Lingxi development platform. It needs to provide some modules to users in the form of product packages, and some modules in the form of source code, and then it is necessary to collude all the modules during development, because different There is business association and authentication between modules.
So when I was writing this framework again, I thought it was not reasonable to put such a special requirement in Alita, and it was too closely related to the business. In the end, this framework might need to be handed over to business developers for maintenance.
It is necessary for this framework to be extremely scalable and extremely difficult to get started. Therefore, the core functions are separated into konos, and the business binding is placed in the local scripts of the scaffold, but at the same time it is mapped to a local executable command. (This is not included in this sharing content)
03 How to use
initialize a frame
Enter the name of the frame according to the prompt, here is an example of hj:
This completes a hj framework. You can use the hj xxx command to start the corresponding cli service, such as the built-in hj inits config, which can generate the configuration file of the hj framework in the current project.
Here are a few examples to show how to write a department-level front-end framework based on konos:
> Unexplained files are all files that are already included in the generated scaffolding
Add the required configuration parameters
src/config/schema.ts
Maybe you don’t know what configuration needs to be added at the beginning, you can come back and add it when you need it, here I list all the configurations I need to use this time for the continuity of the subsequent description.
Publish the built product package to the cloud
Because some modules are provided to users in the form of product packages, a cloud for uploading and downloading is required. If there is a server, you can complete this process according to the interface for uploading and downloading. For the convenience of demonstration, I use npmjs here as my cloud.
This should take into account what framework the docking module is built on, but the normal product package is placed in 'dist' or 'build', so we will find these two directories by default, and of course provide configuration for the user to specify, which is the above Added 'outputPath':
After finding the build product package, it is actually very simple, just create a new 'package.json', and then use 'npm publish' to publish the package to npm.
Create a new file src/commands/publish.ts
Download the package on the cloud to the local
As mentioned earlier, uploading is very simple, you only need to execute 'npm publish', so is it possible to download by executing 'npm install'?
In fact, it depends on whether it meets our needs. 'npm install' will put the subpackage in the 'node_modules' folder, and then the installed modules also need to be written in the project's package.json file, but this package is obviously It has nothing to do with the project we are developing, and it is "difficult" to find after putting it in 'node_modules'. Of course, it is not difficult to find it by package name, but if you need to preview later, it is obviously a big problem to be a file proxy.
So we need to write a specific 'npm install' to fulfill our needs, which requires us to have a certain understanding of the implementation of npm, so we won't expand too much here. In short, it is the download-decompression process.
In addition to executing 'install' according to package.json, npm can also download the specified package to a local file by executing 'npm pack repo@version'. Of course, it should be noted that the downloaded execution directory should not be an npm package , because 'npm pack' is also used to pack and compress the current project, you can simply understand that when you execute 'npm publish', you actually execute 'pack' first and then upload.
You can try it in any empty folder, such as executing 'npm pack [email protected]', you will get the 'xiaohuoni-0.0.1.tgz' file in the current folder, and then use the decompression tool to open it. Get the same content as 'npm install [email protected]', but the storage path is different.
Therefore, all we need to do is simply unzip the file, unzip the file to the directory of its corresponding package name, and use the linux command to complete it:
Since the linux command needs to open the command line tool provided by git on the window to be executed correctly, we use the node package 'tar' to complete it.
In order to speed up the installation process each time, we can add a simple caching mechanism. If the corresponding 'tgz' package already exists locally, the local package will be used instead of downloading from npm.
Regarding the modules that need to be specified for installation, we can do this by adding a configuration 'dependencies':
The usage of dependencies is consistent with the configuration of dependencies in package.json, which has zero understanding cost for front-end personnel.
For example configuration:
We mentioned above that the files will be decompressed to the directory corresponding to the package name, such as '@lingxi-assets/demo', the default decompression path is '/build/demo', and the modules are related to each other, so this file structure, There may be times when flexible configuration is required, so we add a configuration 'paths' to specify the decompression path corresponding to the package name.
Such as configuration:
'@lingxi-assets/demo' will eventually be extracted to the '/build/hello' directory.
Create a new file src/commands/install.ts
Local preview build product
So far, this requirement has been completed. Next, I will give an example of a common requirement of the front-end framework. After the framework is built, we will always open it locally to see if the build products are generated correctly, regardless of the scripts and tests in the build process. How perfect it is, this is also a kind of manual bottom-up behavior, what we often use is 'cd build && serve' which will start a server service on the local port 3000, which can be mapped to the build directory by proxy, so we can easily access 'build /index.html' file to verify the product.
But we often encounter a problem. Local development uses proxy as a proxy to transfer requests, but the proxy may become invalid after the build. Therefore, our current requirement is how to continue to use the proxy configuration after the build.
In fact, we can simply write a command, such as 'hj preview'. In fact, it is an express middleware. We can specify the required data by adding two configurations 'proxy' 'nginx'.
Such as configuration:
According to the above configuration, we can realize that when visiting the home page, it will automatically proxy to the 'demo' directory, and when the request starts with '/server', it will be transferred to the target server, so as long as the proxy is configured and used during development The proxy configuration is consistent, and the nginx configuration corresponds to the nginx used during deployment, so that the cloud deployment can be better restored locally. This is very useful when debugging and verifying.
Create a new file src/commands/preview.ts
04 File structure
I don’t know if you have noticed carefully, the number of lines of code for each of the three functions implemented above does not exceed 100 lines, including blank lines and necessary template codes. This is more difficult to do before using konos, after all, the command line configuration of the simple cli also needs to write a lot of code.
In addition, the files can actually be placed in any directory. In order to better manage the project logically, the template scaffolding distinguishes the folders 'commands' 'config' 'generators' 'inits'. You can follow your Personal preference to reorganize the file structure, just use the file you wrote in the 'src/preset.ts' file in the end.
05 Epilogue
If general frameworks such as 'umi' 'alita' 'fish-x' are called company-level front-end frameworks, then products based on konos are department-level front-end frameworks, which have higher customization and super high Purity, but it also means that it does not come with any function implementation, and every step needs to be implemented by the developer, so if it is a conventional front-end requirement, it is best to choose a company-level front-end framework. After all, the framework gives enough. Fortunately, konos developers only need to master a little node and express knowledge. Of course, you can also use the department-level framework as a functional supplement to the company-level framework. With the flexibility of konos, it is fully compatible with all front-end frameworks.