L'identification du module Seajs github a été expliquée relativement clairement. Mais ce n'est pas exhaustif, surtout lorsque vous devez écrire manuellement [Module ID] et [Module Dependency], ou lorsque vous écrivez vos propres outils automatisés pour le transport (ps : spm ne semble pas très adaptable et facile à utiliser, après tout, tout le monde La structure des répertoires du projet peut varier considérablement et n'est pas facile à modifier. Bien sûr, s'il est positionné comme un outil de gestion de packages, ne vous attendez pas à ce qu'il soit un outil de construction automatisé pour votre projet. doivent être bien compris.
Remarques :
1. Les identifiants de niveau supérieur sont toujours résolus par rapport au chemin de base.
2. Les chemins absolus et les chemins racine sont toujours résolus par rapport à la page actuelle.
3. Les chemins relatifs dans require et require.async sont résolus par rapport au chemin actuel du module.
4. Les chemins relatifs dans seajs.use sont toujours résolus par rapport à la page actuelle.
Dans Seajs, les identifiants de module peuvent être grossièrement divisés en trois types : [identifiant relatif], [identifiant de niveau supérieur], [chemin ordinaire],
les chemins ordinaires incluent "chemin absolu", "chemin racine", etc. .
Ici, nous nous concentrons sur [logo relatif] et [logo de niveau supérieur].
Les identifiants relatifs font référence à ceux commençant par "./", "../", tels que : "./OtherModule", "../lib/Base".
Le logo de niveau supérieur fait référence à celui commençant par un fichier ou un répertoire (peut contenir : des lettres, -, _), tel que : "app/widget/Select"
Il y a trois endroits où vous devez écrire l'ID du module :
Règles d'analyse du chemin de base
(Niveau 1, le chemin lui-même ne dépend d'aucun paramètre)
1 [Logo de niveau supérieur] ne peut pas être utilisé, car le niveau supérieur. le logo est relatif à la base Il est analysé par chemin, donc la base elle-même ne peut utiliser que [identifiant relatif] ou [chemin racine], etc.
2. Le chemin par défaut de base est le répertoire de seajs. Pour d'autres informations, veuillez vous référer au site officiel de seajs. S'il ne s'agit pas de la structure de répertoire de code source recommandée par seajs, essayez de définir le chemin de base manuellement.
3. [Identifiant relatif] : analysé par rapport à la page actuelle.
Règles d'analyse des chemins dans les chemins
(Niveau 1, le chemin lui-même ne dépend d'aucun paramètre)
1 [Identification relative] : Où il est référencé, position d'analyse relative en fonction. là où il est cité, les règles locales s'appliquent.
2. Les champs dans les chemins seront remplacés par les variables là où ils sont utilisés, puis analysés.
Par exemple :
(Niveau 3, le chemin peut être défini par rapport à l'alias ou aux chemins)
Vous pouvez utiliser : [identifiant relatif], [identifiant de niveau supérieur], [chemin racine]
Il est recommandé d'utiliser [ identifiant de niveau supérieur], si le module Si l'emplacement ne se trouve pas dans le chemin de base, utilisez [identifiant relatif] ou [chemin racine].
[Identifiant relatif] : analysé par rapport à la page actuelle
// Module 1, pas d'ambiguïté, résolution du chemin racine
define("/app/src/module/Base", ..);
// Module 2, pas d'ambiguïté, identification de niveau supérieur, par rapport au chemin de base à analyser
define("app/src/module/Base", ..);
// Module 3, il y a une ambiguïté, une identification relative, ici par rapport à la page courante (référencée à cette page html du module)
// Mais même si [apparemment le même "ID"] est utilisé ailleurs, différents modules peuvent être analysés
define("./app/src/module/Base",.. );
Règles d'analyse des ID de dépendance de module (2)
(Niveau 3, les chemins peuvent être définis par rapport à l'alias ou aux chemins)
[Identifiant relatif] : par rapport à l'analyse du chemin de base
//Sans ambiguïté, résolu par rapport au chemin racine
define("..", ["/app/src/module/Base"], ..)
// Identifiant sans ambiguïté de niveau supérieur , Par rapport à l'analyse du chemin de base
define("..", ["app/src/module/Base"], ..)
//Il y a une ambiguïté, une identification relative, ici il est analysé par rapport à le module actuel
//La dépendance ici semble dépendre du `Module 3` dans [Code Block (2)]
//Mais si le module actuel n'est pas dans le même répertoire que la page actuelle, il le fera ne pas être analysé Pour le `Module 3`
define("..", [..], function(require){
//Aucune ambiguïté, résolue par rapport au chemin racine
require("/app/src/module/Base") ;
});
define("..", [..], function(require){
// Identification sans ambiguïté de niveau supérieur, par rapport à l'analyse du chemin de base
require("app/src/module/ Base ");
});
define("..", [..], function(require){
//Il y a une ambiguïté, une identification relative, ici elle est analysée par rapport au module actuel
//Les dépendances ici regardent comme Cela dépend du `Module 3`
dans [Code Block (2)] //Mais si le module actuel n'est pas dans le même répertoire que la page actuelle, il ne sera pas analysé comme `Module 3`
require(" ./app/src/module/Base");
})
Résumé :
1. Les paramètres des chemins et des alias sont simplement équivalents à une variable Partout où elle est utilisée, elle est remplacée par la valeur définie puis analysée.
2. Utilisez [logo de premier niveau] autant que possible.
3. Si [identifiant de niveau supérieur] ne peut pas être utilisé, par exemple, si l'étendue du répertoire est relativement grande, etc., essayez de définir un alias ou des chemins pour localiser un répertoire via un identifiant [chemin non relatif], et puis définissez l'ID sous cet identifiant.