Seajs of analytical rules of modules in the module and summary of the use of modules _seajs

The SEAJS GitHub module logo has been relatively clear. But there is no exhaustive, especially when you need handwriting "module ID" and "module dependencies", or write their own automated tools to do transport (PS:SPM seemingly adaptable is not very strong also difficult to use, after all, the directory structure of each project may vary greatly, and difficult to change. Of course, if he's positioned as a package management tool and don't expect it to be the automated build tool for your project, the parsing rules for IDs need to be thoroughly understood.
Precautions:
1. The top-level identity always resolves relative to the base base path.
2. Absolute and root paths are always relative to the current page resolution.
3. The relative paths in require and require.async are parsed relative to the current module path.
4. The relative path in Seajs.use is always resolved relative to the current page.

In Seajs, the IDs of modules can be roughly divided into three categories: relative identity, top level identification, normal path,
The normal path includes "absolute path", "Root path", and so on.

The emphasis here is on "relative identity" and "top level identification."
Relative identification means "./", ".. /"At the beginning, such as:"./othermodule ",". /lib/base ".
Top-level identification refers to a file or directory (can contain: letter 、-、 _), such as: "App/widget/select"

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

Copy Code code as follows:

Define ("ID (1)", ["..."). /id2 (2) "], function (require, exports, module) {
var Modulea = require ('./modulea (3) ');
})

Note: Whether it is define the first argument "module ID" or the second argument "dependent module ID" or "Require module ID", the final alignment criterion is "parsed file uri".
Therefore, the three places that need to write IDs can be written in any way, as long as the final resolution to the same URI is considered to be the same module.
In the process of parsing IDs, the alias and paths that are defined in Seajs.config are processed in advance.

Base Path resolution rules
(Layer 1th, the path itself is not dependent on any settings)
1. Do not use the "top-level identity" because the top-level identity is resolved relative to the base base path, so base itself can only use "relative identity" or "root path", and so on.
2. The base default path is Seajs directory, other cases see SEAJS official website, if not SEAJS recommended source directory structure, as far as possible manually set the base path.
3. "Relative identification": Resolution on the current page.
Path resolution rules in paths
(Layer 1th, the path itself is not dependent on any settings)
1. "Relative identification": Where to be cited, the relative resolution position depending on where the reference is referred to, following local rules.
2. The fields in the paths are replaced in the way they are used in the variable, and then parsed.
Like what:

Copy Code code as follows:

Code blocks (1)
Path definition:
Seajs.config ({
Base: "./app/src",
path:{
"A": ". /lib ",//(1) Relative path
"Lib": "Path/to/lib",///(2) Top level identification
"L2": "/lib"//(3) Root Path
}
});
Module Mod/m/m.js:
...
Require ("A/jquery");
=> conversion to: ". /.. /lib/jquery "
=> Loading: Mod/lib/jquery (Special note 1)
...
Module Mod/f.js:
...
Require ("A/jquery");
=> conversion to: ". /.. /lib/jquery "
=> Loading: Lib/jquery (Special note 2)
...

path resolution rule in alias
(layer 2nd, the path itself can depend on the paths settings)
1. The rules for Alias are similar to paths, and the alias path can also use the "variable" in paths
2. Reminder: Paths, alias use "top-level id", "Root path", "absolute path", do not use "relative identity", because in different depths of the module reference will resolve to different paths.
3. "Relative identification": Where to be cited, the relative resolution position depending on where the reference is referred to, following local rules.
Seajs.use Path Resolution rules
Relative ID: Parsing from the current page.
define defines module ID resolution rules (1)

(Layer 3rd, the path can be set relative to the alias or paths)
You can use: relative identification, top level identification, root path
It is recommended that you use the "Top level ID" or "relative identity" or "root path" if the location of the module is not within the base base path.
Relative identity: Parsing relative to the current page

Copy Code code as follows:

Code blocks (2)
Config--also uses the configuration in the [code block (1)]

Module 1, no ambiguity, root path resolution
Define ("/app/src/module/base", ...);
Module 2, no ambiguity, top-level identification, relative to the base base path to resolve
Define ("App/src/module/base", ...);
Module 3, ambiguous, relative identification, here compared to the current page (referencing to the HTML page of this module)
But other places can be parsed into different modules even if they use "the same" ID "on the surface".
Define ("./app/src/module/base",..);

Module Dependency ID resolution rule (2)

(Layer 3rd, the path can be set relative to the alias or paths)
"Relative identity": relative base Path resolution

Copy Code code as follows:

Code blocks (3)
Config--also uses the configuration in the [code block (1)]

No ambiguity, relative root path resolution
Define ("..", ["/app/src/module/base"], ...)
No ambiguity, top-level identification, relative to base path resolution
Define ("..", ["app/src/module/base"], ...)
Ambiguous, relative identification, where the current module to resolve
The dependencies here appear to be dependent on ' Module 3 ' in the 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 resolution rules for require other modules within the module (3)
(Layer 3rd, the path can be set relative to the alias or paths)
"Relative identity": relative base Path resolution

Copy Code code as follows:

Code blocks (4)
Config--also uses the configuration in the [code block (1)]

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

Define ("..", [..], function (require) {
No ambiguity, top-level identification, relative to base path resolution
Require ("App/src/module/base");
});

Define ("..", [..], function (require) {
Ambiguous, relative identification, where the current module to resolve
The dependencies here appear to be dependent on ' Module 3 ' in the 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");
})

Special reminder: The three parts of the module need to write ID, do not need to use the same string that looks the same as long as the same module can be resolved.

Summarize:
The 1.paths and alias settings are just equivalent to a variable, where it is used, where it is replaced with a set value and then parsed.
2. Use the "top identification" as much as possible.
3. If you can not use the "top-level identity", such as the directory across the larger, and so on, then try to set the alias or paths through a "non-relative path" identity to navigate to a directory, and then under this identity, and then define the ID.