Que fait systemjs.config.js dans la structure de packaging d'angular 2 ?

Question

Et aussi, que font var map, packages, var config ici, je suis un peu confus. J'ai vu tous les projets et j'ai trouvé partout où ils ont mis ce fichier. Que fait cette fonction ?

 (function(global) {

      // map tells the System loader where to look for things
      var map = {
        'app':                        'app', // 'dist',
        'rxjs':                       'node_modules/rxjs',
        'angular2-in-memory-web-api': 'node_modules/angular2-in-memory-web-api',
        '@angular':                   'node_modules/@angular',
    'primeng':                        'node_modules/primeng'
      };

      // packages tells the System loader how to load when no filename and/or no extension
      var packages = {
        'app':                        { main: 'boot.js',  defaultExtension: 'js' },
        'rxjs':                       { defaultExtension: 'js' },
        'angular2-in-memory-web-api': { defaultExtension: 'js' },
        'primeng':                    { defaultExtension: 'js' }
      };

      var packageNames = [
        '@angular/common',
        '@angular/compiler',
       //
      ];

      // add package entries for angular packages in the form '@angular/common': { main: 'index.js', defaultExtension: 'js' }
      packageNames.forEach(function(pkgName) {
        packages[pkgName] = { main: 'index.js', defaultExtension: 'js' };
      });

      var config = {
        map: map,
        packages: packages
      }

      // filterSystemConfig - index.html's chance to modify config before we register it.
      if (global.filterSystemConfig) { global.filterSystemConfig(config); }

      System.config(config);

    })(this);

Answer 1

Il permet de configurer SystemJS pour charger les modules compilés à l'aide du compilateur TypeScript. Pour les modules anonymes (un module par fichier JS), il permet de faire correspondre le nom des modules aux fichiers JS qui contiennent réellement le code JavaScript du module.

En voici un exemple. Si j'essaie d'importer le module nommé app/test SystemJS fera l'affaire :

• Essayez de trouver un module préenregistré (avec System.register('app/test', ...
• Si ce n'est pas le cas, il va chercher dans sa configuration pour construire la requête à exécuter pour charger le fichier correspondant :
  • il existe un map entrée pour app
  • il existe un packages entrée pour app con defaultExtension = js
• La demande sera http://localhost:3000/app/test.js . Si vous avez map: { app: dist } la demande serait http://localhost:3000/dist/test.js

Answer 2

Le fichier systemjs.config.js définit la configuration pour les éléments suivants Normalisation des chemins dans SystemJS. Vous chargez quelque chose en utilisant SystemJS comme ceci :

System.import('app/main.js')

SystemJS tente alors de charger votre application, en commençant par le fichier app/main.js. L'adresse La toute première chose que fait SystemJS cependant est de normaliser le chemin (app/main.js), ce qui signifie qu'il traduit le chemin d'accès selon les règles de systemjs.config.js.

Systemjs.config.js définit différents types d'alias, pour tout ce qui est importé par SystemJS :

---

carte

La section carte a deux usages :

aliasing du chemin

Dans une application où SystemJS est utilisé pour charger les modules, la section map est utilisée pour aliaser une partie du chemin, ou pour indiquer à SystemJS où se trouve un module nommé particulier. Par exemple, vous pouvez charger votre application en utilisant SystemJS comme ceci :

System.import('app/main.js')

Maintenant, disons que vous voulez effectivement localiser vos fichiers d'application dans :

/assets/js/app.

Vous pouvez le définir dans la section "map" de systemjs.config.js :

// map tells the System loader where to look for things
map: {
  'app': '/assets/js/app'
}

SystemJS cherchera alors votre fichier principal à :

/assets/js/app/main.js

identifier l'emplacement des modules

Le principal objectif fondamental de SystemJS est de fournir un système de modules qui pallie l'absence de prise en charge universelle des modules ES dans les navigateurs, et l'une des façons d'y parvenir est d'utiliser la section "map" de systemjs.config.js pour identifier où chercher les modules.

Pour tous les modules qui sont importés dans votre application à l'aide des instructions ES "import" standard, la section map identifie l'endroit où SystemJS les trouvera (après que votre application ait été chargée avec SystemJS). Voici un exemple courant :

    // map tells the System loader where to look for things
    map: {
        // angular bundles
        '@angular/core': 'npm:@angular/core/bundles/core.umd.js',
        '@angular/common': 'npm:@angular/common/bundles/common.umd.js',
        '@angular/compiler': 'npm:@angular/compiler/bundles/compiler.umd.js',

Cela signifie que lorsque vous faites cela pour la première fois dans votre module Root :

import { NgModule } from '@angular/core';

... SystemJS va gérer l'importation en recherchant la bibliothèque Angular dans son emplacement par défaut (en supposant qu'elle est installée à l'aide de npm) :

/node_modules/@angular/core/bundles/core.umd.js

Vous vous demandez peut-être comment 'npm:' est traduit en '/node_modules'. C'est ce que fait la section 'paths' de systemjs.config.js :

---

chemins

Cette section définit les alias pour les parties des chemins du module qui sont définies dans la section "map". La façon dont 'npm' peut être aliasé dans l'exemple ci-dessus est la suivante :

paths: {
  // paths serve as alias
  'npm:': '/node_modules/'
}

Cela remplacera toutes les occurrences de 'npm', dans tous les chemins que vous avez ajoutés à la section 'map', par la chaîne '/node_modules/'.

Documentation officielle : https://github.com/systemjs/systemjs/blob/master/docs/config-api.md#paths (mort)

---

paquets

Dans la documentation :

Les paquets permettent de définir facilement la configuration des métadonnées et des cartes. qui est spécifique à un chemin commun.

Par exemple, si vous voulez charger votre application comme ceci :

System.import('app')

Vous pouvez ensuite ajouter cette section pour les "paquets" :

    // packages tells the System loader how to load when no filename and/or no extension
    packages: {
        app: {
            main: 'index.js'
            defaultExtension: 'js',
            meta: {
                './*.js': {
                    loader: false,
                }
            }
        }

Voici le détail :

main: 'index.js'

Le point d'entrée principal pour un paquet ou un alias de chemin (s'il n'a pas déjà été fourni dans la section "map").

defaultExtension: 'js'

L'extension de fichier à prendre en compte (si elle n'est pas déjà fournie). Dans ce cas, recherchez un fichier .js si aucun type de fichier n'est spécifié.

meta: {
    './*.js': {
        loader: false,
    }
}

Informations dont SystemJS a besoin pour déterminer comment charger correctement les modules. Dans ce cas, n'invoquez pas le chargeur de modules pour les fichiers '.js' de notre application (vous en auriez besoin si vous utilisez TypeScript - vous voulez que SystemJS charge les modules uniquement lorsque vous transposez le TypeScript, et vous devez ignorer les fichiers .js transposés).

(voir la documentation pour plus d'informations sur 'meta'). https://github.com/systemjs/systemjs/blob/master/docs/config-api.md#meta (mort))

Consultez également la documentation officielle ici pour une explication complète de la section "packages" :

https://github.com/systemjs/systemjs/blob/master/docs/config-api.md#packages (mort)