“This is the first day of my participation in the Gwen Challenge in November. See details of the event: The last Gwen Challenge in 2021”.
preface
Recently, I received A demand to write an SDK(we call it B). Although the business implemented is different, the packaged construction is similar to the SDK written before (call it A). Therefore, I wonder if I can transform the engineering project of A into A universal project to meet other possible needs in the future
Analysis of the
Directory structure of A
In fact, A is A very simple project, the build is just compiled by Babel, then packaged and compressed, and finally output to the specified directory is done
The project directory structure in the first release is shown as follows:
B directory structure
It is assumed that we are going to B on the basis of the project development, we must have to find a path to store B file, because we need an entry documents specified at the time of packaging, so there is a unified management files will be convenient store business So we will be united project files in the SRC, and to create a separate file
Here is the directory structure:
Webpack configuration file
However, we can see that in the webPack configuration file, the entry file is still the same as in the A project entry./ SRC /index.js
/ SRC /A/index.js./ SRC /B/index.js./ SRC /B/index.js
The same is true of the final file that is packaged to build the output
Packjson. json Configuration file
Let’s start by looking at what commands are in package.json in project A
It is also straightforward, and can be packaged by running NPM Run Build
As we mentioned above, the build only works for project A at this point because the package entry file is dead./ SRC /index.js and we obviously need to start with the entry file
implementation
From the above analysis, we can list the following things that need to be done:
- Entry file adaptation
- Final package file location adaptation
As you can see, we mainly work around the input and output of different project files, and one of the key elements is to distinguish project sources
Distinguish between different project names
The command line argument process.argv
The process.argv property returns an array containing the command-line arguments passed in when the Node.js process is started. The first element will be process.execPath. The second element will be the path to the JavaScript file being executed. The remaining elements will be any other command line arguments. (Excerpt from official document)
From this we can see that we can pass in the parameters we want on the command line, so that we can pass in different parameters for different projects to distinguish between them
So we can modify the build command and execute it:
The first and second parameters are node and project path respectively. The rest of the elements are the command parameters that we pass in, so we can write commands that carry different parameters to distinguish the project’s source
Pack to build
Access to the process. Argv
As you can see from the screenshot above, we have printed the command line parameters for the custom input parameter on the console, and now that they are printed, they can be retrieved
When we fetch it in the webpack.config.js configuration file, we also fetch it through process.argv and treat it as an array.
Remember the directory structure after B was mixed in with project A. We stored all the projects separately in the SRC folder. In this case, we only needed to fill in the dynamically obtained project name when writing the entry and exit files
Then each time you package and build a different project, you simply execute the corresponding command line