Detailed explanation of module parsing rules and module usage Summary In seajs

The ID of the seajs github module is clear. However, it is not comprehensive, especially when you need to hand-write [module ID] and [module dependency], or write your own automated tools for transport (ps: spm seems to be not very adaptable and easy to use. After all, the directory structure of each project may vary greatly and is not easy to change. Of course, if his positioning is the package management tool, don't expect it to be an automated building tool for your project), the ID parsing rules need to be thoroughly understood.
Note:
1. The top-level identity is always parsed relative to the base path.
2. the absolute path and root path are always parsed relative to the current page.
3. The relative paths in require and require. async are parsed relative to the current module paths.
4. The relative path in seajs. use is always parsed relative to the current page.

In seajs, the module ID can be roughly divided into three types: Relative ID, top-level ID, and common path ],
Common paths include "absolute path" and "root path.

Here we will focus on [Relative ID] and [top-level id ].
A relative identifier starts with "./", ".../", for example, "./OtherModule", "./lib/Base ".
Top-level identifiers start with a file or directory (which can contain letters,-, and _), for example, "app/widget/Select"

There are three places where the module ID needs to be written:
Copy codeThe Code is as follows: define ("id (1)", ["../id2 (2)"], function (require, exports, module ){
Var moduleA = require ('./moduleA (3 )');
})
Note: whether it is the first define parameter [module ID], the second parameter [dependent module ID], or the require module ID ], the final comparison criterion is [parsed file URI ].
Therefore, the ID must be written in any way. As long as it is parsed as the same URI, it is considered to be the same module.
In the process of parsing the ID, it will be processed by the alias and paths defined in seajs. config in advance.

Base path parsing rules
(Layer 3, its own path does not depend on any settings)
1. You cannot use the top-level identity. Because the top-level identity is parsed relative to the base path, the base can only use the relative identity or root path.
2. The default base path is the seajs directory. For other cases, see the seajs official website. If it is not the source code directory structure recommended by seajs, set the base path manually.
3. [relative identifier]: parses the file relative to the current page.
Path parsing rules in paths
(Layer 3, its own path does not depend on any settings)
1. [relative identification]: the location where the domain name is referenced. The relative resolution location depends on the location where the domain name is referenced and follows the local rules.
2. Fields in paths will be replaced by variables in use and then parsed.
For example:
Copy codeCode: // code block (1)
// Path definition:
Seajs. config ({
Base: "./app/src ",
Path :{
"A": "../lib", // (1) Relative Path
"Lib": "path/to/lib", // (2) Top-level ID
"L2": "/lib" // (3) root path
}
});
// Module mod/m. js:
...
Require ("a/jquery ");
// => Convert to: ".../../lib/jquery"
// => Load: mod/lib/jquery (Note 1)
...
// Module mod/f. js:
...
Require ("a/jquery ");
// => Convert to: ".../../lib/jquery"
// => Load: lib/jquery (note 2)
...
Path parsing rules in alias
(Layer 3, the path itself can depend on paths settings)
1. the alias rule is similar to paths, and the alias path can also use the "variable" in paths"
2. reminder: use top-level identifiers, root paths, and absolute paths in paths and alias. Do not use relative identifiers ], because the module references in different depths are resolved to different paths.
3. [relative identification]: the location where the domain name is referenced. The relative resolution location depends on the location where the domain name is referenced and follows the local rules.
Seajs. use path parsing rules
[Relative identifier]: parses the image relative to the current page.
Define defines the module ID parsing rules (1)

(Layer 3, path can be set relative to alias or paths)
You can use: Relative ID, top-level ID, and root path]
We recommend that you use the top-level ID. If the module is not located in the base path, use the Relative ID or root path ].
[Relative ID]: parses relative to the current page
Copy codeCode: // code block (2)
// Config -- use the configuration in [code block (1 )]

// Module 1, unambiguous, root path Parsing
Define ("/app/src/module/Base ",..);
// Module 2, non-ambiguous, top-level identifier, Which is parsed relative to the base path
Define ("app/src/module/Base ",..);
// Module 3, which has ambiguity and relative identifier. This parameter is relative to the current page (the html page referenced to this module)
// However, even if the same "ID" is used elsewhere, different modules may be parsed.
Define ("./app/src/module/Base ",..);

Module dependency ID parsing rules (2)

(Layer 3, path can be set relative to alias or paths)
[Relative ID]: relative base path Parsing
Copy codeCode: // code block (3)
// Config -- use the configuration in [code block (1 )]

// No ambiguity, relative to root path Parsing
Define ("...", ["/app/src/module/Base"],...)
// Unambiguous, top-level identifier, relative to base path Parsing
Define ("...", ["app/src/module/Base"],...)
// Ambiguous and relative identifier. This parameter is resolved relative to the current module.
// The dependency here seems to be dependent on 'module 3' in [code block (2'
// However, if the current module is not in the same directory as the current page, it will not be parsed as 'module 3'
Define ("...", ["./app/src/module/Base"],...)
ID parsing rules of other require modules in the module (3)
(Layer 3, path can be set relative to alias or paths)
[Relative ID]: relative base path Parsing

Copy codeCode: // code block (4)
// Config -- use the configuration in [code block (1 )]

Define ("...", [...], function (require ){
// No ambiguity, relative to root path Parsing
Require ("/app/src/module/Base ");
});

Define ("...", [...], function (require ){
// Unambiguous, top-level identifier, relative to base path Parsing
Require ("app/src/module/Base ");
});

Define ("...", [...], function (require ){
// Ambiguous and relative identifier. This parameter is resolved relative to the current module.
// The dependency here seems to be dependent on 'module 3' in [code block (2'
// However, 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 ");
})
Note: The ID must be written in three parts of the module. You do not need to use strings that look the same, as long as they are parsed into the same module.

Summary:
1. The setting of paths and alias is only equivalent to a variable. Replace it with the set value where it is used, and then parse it.
2. Try to use the top-level logo ].
3. if you cannot use a top-level identifier, such as a large directory, set alias or paths to locate a directory through a non-relative path identifier, and then under this identifier, then define the ID.