When FIS3+mod.js development plan is deployed online, there is a bug resolution process where files cannot be found.

  debug, fis3, mod.js

In the project, we chose Baidu FIS3+MODJS+VUEJS for front-end development. The details of this scheme can be seen here:
https://github.com/zhangtao07/fis-vuejs-seed

The local development process was very smooth, and the first online deployment was also very smooth. Everything seemed to be going smoothly. However, after an update deployment this morning, unexpected things happened.

We updated the code online by putting the files from fis3 release into the server file directory and restarting the server. There were no problems in the previous revisions, but this morning, I added two newly written js files to the server file directory. After following the previous update method, I found that the console reported an error, and the reason for the error was that mod.js could not find the corresponding js file.

The project is loaded asynchronously, and js will directly require it whenever it is needed. This morning’s bug appeared here, and the two newly added js files did not come out.

First of all, I carefully checked the reference path of the file, and the writing method of the file that can be loaded successfully is exactly the same, eliminating the problem of the file path.
Then debug other pages, because I have tried before that if the previous page reported an error, it would affect the progress of this page. After the errors of other pages are eliminated, the problem still exists.
Open chrome console, monitor file request in network, find 404 error in require path report, and find that its content-type is text instead of normal javascript. At the same time, my colleague’s unintentional remark also caught my attention: “It’s strange that it can be deployed for the first time, and it is no problem to modify the code inside, but there is a problem to change the name of the file or add a new file.”

Through careful analysis, it is believed that this bug is not caused by low-level errors such as writing the wrong path, but by problems during FIS3 compilation or mod.js file reference.

With this idea in mind, I first studied FIS3′ s config file and found no key points. The preliminary exclusion is the problem of FIS3 compilation.
Then on github, I found the mod.js project where Baidu fex-team is located, and found that there was such a question:
https://github.com/fex-team/mod/issues/16#issuecomment-100741125
The key point is this sentence:

Mod.js does not exist as a complete loader at the time of output. in order to match fis’ functions including md5, cdn, etc., it is necessary to give mod.js a static resource list when loading and using it.

I think I found the reason.
Mod.js is not written directly inrequire('xxxxx')In this way, the file can be imported through a static list of resources. If this table does not record this path, mod.js cannot load resources into it.

This list is obtained by the backend by querying the static resource list map.json produced by fis.

In other words, this table should be in my FIS3 output directory or output file. After opening the server directory, find the corresponding file, really found that there is such a static resource list:

require.resourceMap({
 "res": {
 "project/component/xxx/xx": {
 "url": "/project/component/xxx/xx.js",
 "type": "js"
 },
 "pkg":[]
 });

The problem is finally clear. It turned out that we only wanted to add new files and update the reference path of resources, but did not update this static resource list! This is why the deployment was successful for the first time, but there was a bug when modifying the file name or adding a new file (because this static resource list was stored in a file that hardly needed to be changed, this file was still in the old version when deploying online).
Immediately update this static resource list, deploy, restart the server, test …
The test passed.
Bug finally resolved! !

In retrospect, this was actually a low-level mistake, because the step of comparing the contents of the files before deployment was omitted. Not familiar with the compiling process of the building tools and not knowing the loading principle of the module loader are also the causes of the bug. In the future, we must know every link well in the development so as to avoid problems in the knowledge gap.