Cet article vous apporte une explication (exemple de code) sur le fichier angulaire.json. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.
Après la version Angular CLI 6+, le fichier angulaire-cli.json d'origine a été remplacé par angulaire.json, et les champs qu'il contient ont beaucoup changé si vous ne comprenez pas la composition de base, ou directement. Copier l'ancienne version du code dans la nouvelle version de l'espace de travail entraînera des erreurs très désagréables.
Ce changement est principalement dû à l'introduction du modèle de développement monorepo (un espace gère plusieurs projets) dans Angular CLI, c'est-à-dire que l'utilisation de ng new équivaut à un grand espace de travail, qui est géré via angulaire.json. configuration. Divers projets ou bibliothèques de composants de la bibliothèque d'application ng generate |
En fait, les avantages de ce modèle sont très évidents. Par exemple, lorsqu'une entreprise dispose de plusieurs plateformes ou produits de gestion, cette méthode peut unifier l'environnement de chaque projet, et les composants partagés entre chaque projet peuvent également le faire. être maintenu de manière uniforme, tous les projets partagent des packages npm et des configurations dactylographiées.
La structure sous monorepo est la suivante :
Mais en fait, la plupart des gens conservent toujours un espace de travail et un projet, donc ce n'est pas ici. Si important, je veux juste dire que les modifications apportées au fichier json concernent le nouveau modèle.
Certains champs d'Angular.json
Lorsque vous créez un nouvel espace de travail, un projet et le projet e2e correspondant seront créés par défaut dans le répertoire racine. La structure initiale d'angular.json est la suivante (la partie omise du code de configuration)
{ "$schema": "./node_modules/@angular/cli/lib/config/schema.json", "version": 1, "newProjectRoot": "projects", "projects": { "xxxx": { "root": "", "sourceRoot": "src", "projectType": "application", "prefix": "app", "schematics": {}, "architect": {} } }, "defaultProject": "xxxx" }
Cela fait partie des propriétés de configuration, je vais simplement les enregistrer dans l'ordre afin qu'elles puissent être référencées ultérieurement.
$schema
pointe vers un fichier de schéma JSON, qui décrit tous les champs et contraintes d'angular.json.
En fait, il peut être comparé à un fichier avec une fonction "type prompt". Tant qu'un IDE ou un éditeur prenant en charge cette fonction donnera les invites correspondantes lors de l'écriture du fichier angulaire.json.
version
Définir la version
newProjectRoot
Le chemin où se trouve le nouveau projet.
Lors de l'utilisation de la bibliothèque d'application ng generate | pour créer un nouveau projet, il sera automatiquement assemblé dans le répertoire newProjectRoot défini
projets
Configuration de tous les projets. L'un des projets est un sous-élément. Par exemple, xxxx est un projet généré automatiquement lors de sa création.
{ "projects": { "xxxx": { "root": "", "sourceRoot": "src", "projectType": "application", "prefix": "app", "schematics": {}, "architect": {} } } }
Dans une seule configuration, certaines opérations d'automatisation peuvent être réalisées grâce à une configuration flexible et à l'aide de certaines des commandes intégrées de la CLI.
root
représente le "répertoire racine" du projet, qui est l'emplacement du projet, ou le répertoire parent du code source du projet. Le répertoire racine du projet contient une configuration spécifique.
sourceRoot
Le répertoire où se trouve le code source du projet Le répertoire src est généralement utilisé par défaut.
projectType
Indiquez si ce projet est une application ou une bibliothèque
préfixe
Utiliser le composant ng generate | Le préfixe du sélecteur par défaut lorsque la directive génère des composants ou des instructions. Habituellement, les composants ou les instructions que nous créons à l'aide de commandes sont au format app-xxx. Nous pouvons le modifier manuellement ici pour rendre l'ensemble du projet efficace.
schémas
Les instructions de la CLI pour générer des composants, des instructions, des modules et d'autres fichiers sont implémentées à l'aide de @angular-devkit/schematics. configurations de raccourci, par exemple, une commande pour générer des composants : ng g c --spec=false --styleext=scss Cette commande peut générer directement un composant sans fichier de test et en utilisant scss comme fichier de style. Ce serait gênant si vous deviez saisir manuellement ces configurations à chaque fois, donc angulaire.json fournit l'attribut schématique pour définir uniformément certaines configurations de commandes pour générer des classes.
Les schémas ici concernent un seul projet. L'ensemble du fichier angulaire.json possède également ce champ, qui prend effet par défaut dans tous les projets.
CLI prédéfinit plusieurs ensembles d'options, et nous pouvons configurer différentes options :
@schematics/angular:component
@schematics/angular:class
@schematics/angular:directive
@schematics/angular:guard
@schematics/angular:module
@schematics/angular:pipe
@schematics /angular:service
Prenons le composant comme exemple Si vous souhaitez obtenir l'effet unifié de ng g c --spec=false --styleext=scss, vous pouvez le configurer comme suit :
{ "schematics": { "@schematics/angular:component": { "styleext": "less", "spec": false } } }
Ensuite, vous pouvez utiliser directement ng g c pour générer directement les composants correspondants.
architect
contient plusieurs ensembles de configurations de commandes d'automatisation de projet liées à la CLI, telles que l'exécution locale, la compilation, les tests, etc. Plusieurs ensembles de configurations de commandes sont prédéfinis par défaut, comme build, serve, etc. :
{ "architect":{ "build":{}, "serve":{}, "extract-i18n":{}, "test":{}, "lint":{} } }
Attributs de configuration
Chaque élément de configuration possède 3 attributs de champ : builder , options, configurations, telles que la configuration par défaut de la commande build :
{ "architect": { "build": { "builder": "@angular-devkit/build-angular:browser", "options": { "outputPath": "dist/testApp", "index": "src/index.html", "main": "src/main.ts", "polyfills": "src/polyfills.ts", "tsConfig": "src/tsconfig.app.json", "assets": [ "src/favicon.ico", "src/assets" ], "styles": [ "src/styles.css" ], "scripts": [] }, "configurations": { "production": { "fileReplacements": [ { "replace": "src/environments/environment.ts", "with": "src/environments/environment.prod.ts" } ], "optimization": true, "outputHashing": "all", "sourceMap": false, "extractCss": true, "namedChunks": false, "aot": true, "extractLicenses": true, "vendorChunk": false, "buildOptimizer": true } } } } }
Il s'agit de la configuration générée par le projet par défaut.
builder代表要执行的内置程序,因为CLI内置了一些自动化工具,architect只是提供了一个facade模式(通俗地讲,就是开发者不需要知道内部的复杂实现)给开发者配置使用,本质上还是调用的内置工具。
options代表针对当前builder要配置的配置项,调用不同的内置程序,是需要传对应的配置项的,由于配置项很多,这里也不会列出。
configurations代表这个命令的多种调用模式,在此配置里,我们可以定义不同的别名,然后使用不同的配置(配置的字段还是属于options里的),最后在使用命令时便可以手动选择不同的模式。
如何使用
CLI其实内置了几个快捷命令来对应默认生成的配置如ng serve、ng build等等,如果是我们额外自定义的配置,则可以使用ng run
命令来实现,其中project和architect为必填,configurations为选填。
比如我们简单额外自定义一个本地运行的服务器命令:
{ "architect":{ "myServe":{ "builder": "@angular-devkit/build-angular:dev-server", "options": { "browserTarget": "xxxx:build", "port": 8800 }, "configurations": { "port1": { "port": 8801 }, "port2": { "port": 880 } } } } }
配置使用了内置的运行本地服务器程序,然后使用默认的build配置,加上自定义的运行端口,另外加上两个不同模式,运行不同端口。
使用ng run xxxx:myServe可以正常运行本地服务器跑项目,端口是8800
使用ng run xxxx:myServe:port1端口是8801
当然,我们还可以直接使用额外的命令行配置直接覆盖已经定义的配置:
ng run xxxx:myServe:port1 --port=8808
这里的例子只是为了简单了解下architect的用法。
defaultProject
默认项目,当使用一些CLI命令没有指定项目名称时,默认指向的项目。
schema.json
其实我只是为了记录自己有点印象的属性,整个angular.json还有很多其他的字段,如果想要全面了解,我们可以直接打开$schema所指向的文件,里面详细地展示了各种字段的类型、配置以及描述说明。
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!