Detailed explanation of the parsing rules of modules in seajs and summary of module usage_Seajs

Seajs github module identification has been explained relatively clearly. But it is not exhaustive, especially when you need to hand-write [Module ID] and [Module Dependency], or when you write your own automated tools for transport (ps: spm seems not very adaptable and easy to use, after all, everyone The directory structure of the project may vary greatly and is not easy to change. Of course, if it is positioned as a package management tool, don't expect it to be an automated build tool for your project). The ID parsing rules need to be understood thoroughly.
Notes:
1. Top-level identifiers are always resolved relative to the base path.
2. Absolute paths and root paths are always resolved relative to the current page.
3. Relative paths in require and require.async are resolved relative to the current module path.
4. Relative paths in seajs.use are always resolved relative to the current page.

In seajs, module IDs can be roughly divided into three types: [relative identifier], [top-level identifier], [ordinary path],
ordinary paths include "absolute path", "root path", etc.

Here we focus on [relative logo] and [top-level logo].
Relative identifiers refer to those starting with "./", "../", such as: "./OtherModule", "../lib/Base".
The top-level logo refers to the one starting with a file or directory (can contain: letters, -, _), such as: "app/widget/Select"

There are three places where you need to write the module ID:

Copy the code The code is as follows:

define(" id (1)",["../id2 (2)"], function(require, exports, module){
var moduleA = require('./moduleA (3)');
})

Note: Whether you define the first parameter [Module ID] or the second parameter [Dependent Module ID] or [Require Module ID], the final comparison standard is [Parsed File URI] .
Therefore, these three places where ID needs to be written can be written in any way. As long as they are ultimately resolved to the same URI, they are considered to be the same module.
In the process of parsing the ID, the alias and paths defined in seajs.config will be processed in advance.

base path parsing rules
(Level 1, the path itself does not depend on any settings)
1. [Top-level logo] cannot be used, because the top-level logo is relative to the base It is parsed by path, so the base itself can only use [relative identifier] or [root path], etc.
2. The default path of base is the directory of seajs. For other information, please refer to the seajs official website. If it is not the source code directory structure recommended by seajs, try to set the base path manually.
3. [Relative identifier]: parsed relative to the current page.
Path parsing rules in paths
(Level 1, the path itself does not depend on any settings)
1. [Relative identification]: where it is referenced, relative parsing position Depending on where it is cited, local rules apply.
2. The fields in paths will be replaced by variables where they are used, and then parsed.
For example:

Copy code The code is as follows:

//Code block (1)
//path definition:
seajs.config({
base:"./app/src",
path:{
"a":"../lib", //(1 ) Relative path
"lib":"path/to/lib", //(2) Top-level identifier
"l2":"/lib" //(3) Root path
}
});
//Module mod/m/m.js:
...
require("a/jquery");
//=> Convert to: "../ ../lib/jquery"
//=> Loading: mod/lib/jquery (Special note 1)
...
//Module mod/f.js:
.. .
require("a/jquery");
//=> Convert to: "../../lib/jquery"
//=> Load: lib/jquery (special Note 2)
...

Path parsing rules in alias
(Layer 2, the path itself can depend on the settings of paths)
1. The rules of alias are similar to paths, and alias paths can also be used "Variables" in paths
2. Reminder: Try to use [top-level identifier], [root path], [absolute path] in paths and alias. Do not use [relative identifier], because it will be affected when modules of different depths are referenced. Resolves to a different path.
3. [Relative Identification]: Where it is referenced, the relative parsing position depends on the place where it is referenced and follows local rules.
seajs.use path resolution rules
[Relative identifier]: parsed relative to the current page.
define defines module ID parsing rules (1)

(Level 3, the path can be set relative to alias or paths)
You can use: [relative identifier], [top-level identifier], [root path]
It is recommended to use [top-level identifier], if the module If the location is not within the base path, use [relative identifier] or [root path].
[Relative identifier]: parsed relative to the current page

Copy code The code is as follows:

// Code block (2)
//config -- also uses the configuration from [code block (1)]

// Module 1, no ambiguity, root path resolution
define("/app/src/module/Base", ..);
// Module 2, no ambiguity, top-level identification, relative to base base path to parse
define("app/src/module/Base", ..);
// Module 3, there is ambiguity, relative identification, here relative to the current page (referenced to this module html page)
// But even if the [ostensibly the same "ID"] is used elsewhere, different modules may be parsed
define("./app/src/module/Base",.. );

Module dependency ID parsing rules (2)

(Level 3, paths can be set relative to alias or paths)
[Relative identifier]: relative to base base path analysis

Copy code The code is as follows:

//Code block (3)
//config -- Also use the configuration in [Code block (1)]

//Unambiguous, resolved relative to the root path
define("..", ["/app/src/module/Base"], ..)
// Unambiguous, top-level identifier, Relative to base base path parsing
define("..", ["app/src/module/Base"], ..)
//There is ambiguity, relative identification, here it is parsed relative to the current module
//The dependency here seems to depend on `Module 3` in [Code Block (2)]
//But if the current module is not in the same directory as the current page, it will not be parsed For `Module 3`

define("..", ["./app/src/module/Base"],..)
require ID parsing rules of other modules in the module (3)
(Level 3, the path can be set relative to alias or paths)
[Relative identifier]: Relative to base basic path analysis

Copy code The code is as follows:

//Code block (4)
//config -- Also uses configuration from [code block (1)]

define("..", [..], function(require){
//No ambiguity, resolved relative to the root path
require("/app/src/module/Base");
});

define("..", [..], function(require){
// Unambiguous, top-level identification, relative to base base path analysis
require("app/src/module/Base ");
});

define("..", [..], function(require){
//There is ambiguity, relative identification, here it is parsed relative to the current module
//The dependencies here look like It depends on `Module 3`
in [Code Block (2)] //But if the current module is not in the same directory as the current page, it will not be parsed as `Module 3`
require(" ./app/src/module/Base");
})

Special reminder: The three places in the module where IDs need to be written do not need to use strings that look the same, as long as they are parsed as Just the same module.

Summary:
1. The settings of paths and alias are just equivalent to a variable. Wherever it is used, it is replaced with the set value and then parsed.
2. Use [top-level logo] as much as possible.
3. If [top-level identifier] cannot be used, for example, the directory span is relatively large, etc., try to set alias or paths to locate a directory through a [non-relative path] identifier, and then define the ID under this identifier.