Module parsing rules in seajs and module usage summary

The seajs github module identity is relatively clear. However, it doesn't cover everything, especially when you need to write module ID and module dependency by hand, or write your own automation tool to do transport (ps: SPM seems not very adaptable and difficult to use, after all, the directory structure of each project may be very different and 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.
Notes:
1. The top-level identity is always resolved relative to the base base path.
2. The absolute path and root path are always relative to the current page resolution.
3. The relative path in require and require.async is resolved relative to the current module path.
4. The relative path in seajs.use is always resolved relative to the current page.

In seajs, module ids can be roughly divided into three types: [relative identification], [top-level identification], [common path],
Common paths include "absolute path", "root path", etc.

The emphasis here is on relative identification and top-level identification.
Relative identification means "./",".. /" at the beginning, e.g. "./OtherModule", ".. / lib/Base ".
Top-level identifiers are those that begin with a file or directory (which can contain: letters, -, _), such as "app/widget/Select"

There are three places where the module ID needs to be written:

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

Note: whether the first parameter [module ID] or the second parameter [dependent module ID] or [require module ID] is defined, the final comparison criterion is [parsed file URI].
Therefore, the three places where the ID needs to be written can be written either way, as long as they end up being resolved to the same URI, which is considered the same module.
As the ID is resolved, aliases and paths defined in seajs.config are processed in advance.

Base path resolution rule
(layer 1, its path does not depend on any Settings)
1. Do not use the top-level identifier, because the top-level identifier is resolved relative to the base base path, so the base itself can only use the relative identifier or the root path.
2. The default path of base is seajs directory. For other information, please refer to the seajs official website.
3. [relative identification] : relative to the current page analysis.
Path resolution rules in paths
(layer 1, its path does not depend on any Settings)
1. [relative identification] : where is referenced, the relative resolution position depends on the place of reference, following local rules.
2. The fields in paths are replaced as variables where they are used and then resolved.
Such as:

//Code block (1)
//The path definition:
seajs.config({
    base:"./app/src",
    path:{
        "a":"../lib", //(1) relative path
        "lib":"path/to/lib", //(2) top-level identification
        "l2":"/lib" //(3) the root path
    }
});
//Module mod/m/modes s:
...
require("a/jquery");
//=> Convert to: ".. /.. / lib/jquery"
//=> Load: mod/lib/jquery (special note 1)
...
//Module mod/f.j s:
...
require("a/jquery");
//=> Convert to: ".. /.. / lib/jquery"
//=> Load: lib/jquery (special note 2)
...

Path resolution rules in alias
(layer 2, its path can depend on the setting of paths)
1. Alias's rules are similar to paths, and alias paths can also use "variables" in paths
2. Reminder: try to use [top-level identifier], [root path], and [absolute path] in paths and aliases instead of [relative identifier], as different depth of module references will resolve to different paths.
3. [relative identification] : where is referenced, the relative resolution position depends on the place of reference, following local rules.
Seajs. use path resolution rules
Relative identification: relative to the current page resolution.
Define module ID resolution rule (1)

(layer 3, paths can be set relative to alias or paths)
Can be used: [relative identification], [top-level identification], [root path]
It is recommended to use a top-level identifier, or a relative identifier or a root path if the location of the module is not in the base base path.
Relative identification: relative to the current page analysis

//Code block (2)
//Config -- also USES the configuration in [code block (1)]
//Module 1, unambiguous, root path resolution
define("/app/src/module/Base", ..);
//Module 2, unambiguous, top-level identity, parsed relative to base base path
define("app/src/module/Base", ..);
//Module 3, ambiguous, relative identifier, here relative to the current page (HTML page referenced to this module)
//But elsewhere, even if you use [ostensibly the same "ID"], different modules may be parsed
define("./app/src/module/Base",..);

Module dependent ID resolution rule (2)

(layer 3, paths can be set relative to alias or paths)
[relative identification] : relative base base path resolution

//Code block (3)
//Config -- also USES the configuration in [code block (1)]
//Unambiguous, relative to root path resolution
define("..", ["/app/src/module/Base"], ..)
//Unambiguous, top-level identity, relative to base base path resolution
define("..", ["app/src/module/Base"], ..)
//Ambiguity, relative identity, here relative to the current module to resolve
//The dependency here appears 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 to  ` The module 3`

Define (".." [". / app/SRC/module/Base "],..)
ID resolution rule requiring other modules within the module (3)
(layer 3, paths can be set relative to alias or paths)
[relative identification] : relative base base path resolution

//Code block (4)
//Config -- also USES the configuration in [code block (1)]
define("..", [..], function(require){
    //Unambiguous, relative to root path resolution
    require("/app/src/module/Base");
});
define("..", [..], function(require){
    //Unambiguous, top-level identity, relative to base base path resolution
    require("app/src/module/Base");
});
define("..", [..], function(require){
    //Ambiguity, relative identity, here relative to the current module to resolve
    //The dependency here appears 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 resolved to 'module 3'
    require("./app/src/module/Base");
})

Special note: there are three places in the module where you need to write an ID. You don't need to use the same string, just parse it into the same module.

Conclusion:
1. The setting of paths and aliases is just like a variable, where it is used, it is replaced with the set value, and then resolved.
2. Use top-level logos whenever possible.
3. If top-level identifiers cannot be used, such as large directory spans, etc., try to set aliases or paths to a directory with a [non-relative path] identifier, and then define ids under that identifier.