Dieser Artikel enthält eine Erklärung der Datei „angular.json“ (Codebeispiel), die einen gewissen Referenzwert hat. Ich hoffe, dass sie für Sie hilfreich ist.
Nach der Angular CLI 6+-Version wurde die ursprüngliche Datei „angular-cli.json“ durch „angular.json“ ersetzt, und die darin enthaltenen Felder haben sich stark geändert, wenn Sie den grundlegenden Aufbau nicht verstehen Das Kopieren der alten Version des Codes in die neue Version des Arbeitsbereichs führt zu einigen sehr unfreundlichen Fehlern.
Diese Änderung ist hauptsächlich auf die Einführung des Monorepo-Entwicklungsmodells (ein Bereich verwaltet mehrere Projekte) in Angular CLI zurückzuführen. Das heißt, die Verwendung von ng new entspricht einem großen Arbeitsbereich, der über angle.json verwaltet wird Konfiguration. Verschiedene Projekte oder Komponentenbibliotheken aus der NG Generate-Anwendungsbibliothek.
Tatsächlich liegen die Vorteile dieses Modells auf der Hand. Wenn ein Unternehmen beispielsweise über mehrere Verwaltungsplattformen oder Produkte verfügt, kann diese Methode die Umgebung jedes Projekts vereinheitlichen, und dies gilt auch für die von den einzelnen Projekten gemeinsam genutzten Komponenten einheitlich gepflegt werden, alle Projekte teilen sich NPM-Pakete und TypeScript-Konfigurationen.
Die Struktur unter Monorepo ist wie folgt:
Aber tatsächlich pflegen die meisten Leute immer noch einen Arbeitsbereich und ein Projekt, also Das ist hier nicht so wichtig. Ich möchte nur sagen, dass die Änderungen an der JSON-Datei für das neue Modell gelten.
Einige Felder von Angular.json
Wenn Sie einen neuen Arbeitsbereich erstellen, werden standardmäßig ein Projekt und das entsprechende E2E-Projekt im Stammverzeichnis erstellt. Die anfängliche Angular.json-Struktur ist wie folgt (der weggelassene Teil des Konfigurationscodes)
{ "$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" }
Dies ist Teil der Konfigurationseigenschaften, damit sie später leicht referenziert werden können.
$schema
verweist auf eine JSON-Schemadatei, die alle Felder und Einschränkungen von angle.json beschreibt.
Tatsächlich kann es mit einer Datei mit einer „Eingabeaufforderung“-Funktion verglichen werden, sofern eine IDE oder ein Editor, der diese Funktion unterstützt, beim Schreiben der Datei „angular.json“ entsprechende Eingabeaufforderungen ausgibt.
Version
Set-Version
newProjectRoot
Der Pfad, in dem sich das neue Projekt befindet.
Wenn Sie die ng generic application | verwenden, um ein neues Projekt zu erstellen, wird es automatisch im festgelegten newProjectRoot-Verzeichnis
Projekte
zusammengestellt alle Projekte. Eines der Projekte ist beispielsweise ein Unterpunkt, xxxx ist ein Projekt, das beim Erstellen automatisch generiert wird.
{ "projects": { "xxxx": { "root": "", "sourceRoot": "src", "projectType": "application", "prefix": "app", "schematics": {}, "architect": {} } } }
In einer einzigen Konfiguration können einige Automatisierungsvorgänge durch flexible Konfiguration und einige in die CLI integrierte Befehle realisiert werden.
root
stellt das „Stammverzeichnis“ des Projekts dar, also den Speicherort des Projekts, oder das übergeordnete Verzeichnis des Projektquellcodes. Das Stammverzeichnis des Projekts enthält eine bestimmte Konfiguration.
sourceRoot
Das Verzeichnis, in dem sich der Projektquellcode befindet. Das src-Verzeichnis wird normalerweise standardmäßig verwendet.
Projekttyp
Geben Sie an, ob es sich bei diesem Projekt um eine Anwendung oder eine Bibliothek handelt.
Präfix
Verwenden Sie die Generierungskomponente |. Das Standard-Selektorpräfix, wenn die Direktive Komponenten oder Anweisungen generiert, hat normalerweise das Format app-xxx. Wir können es hier manuell ändern, um das gesamte Projekt wirksam zu machen.
Schemata
Die Anweisungen in der CLI zum Generieren von Komponenten, Anweisungen, Modulen und anderen Dateien werden mit @angular-devkit/schematics implementiert. Diese Anweisungen sind normalerweise im Lieferumfang enthalten Shortcut-Konfigurationen, zum Beispiel ein Befehl zum Generieren von Komponenten: ng g c --spec=false --styleext=scss Dieser Befehl kann eine Komponente direkt generieren, ohne eine Testdatei und unter Verwendung von scss als Stildatei. Es wäre mühsam, wenn Sie diese Konfigurationen jedes Mal manuell eingeben müssten. Angular.json stellt daher das Schematics-Attribut bereit, um einige Befehlskonfigurationen zum Generieren von Klassen einheitlich festzulegen.
Die Schaltpläne hier beziehen sich auf ein einzelnes Projekt. Auch die gesamte angle.json verfügt über dieses Feld, das standardmäßig in allen Projekten wirksam wird.
CLI stellt mehrere Optionssätze vor, und wir können verschiedene Optionen konfigurieren:
@schematics/angular:component
@schematics/angular:class
@schematics/angular:directive
@schematics/angular:guard
@schematics/angular:module
@schematics/angular:pipe
@schematics /angular:service
Nehmen Sie die Komponente als Beispiel. Wenn Sie den Effekt eines einheitlichen ng g c --spec=false --styleext=scss erzielen möchten, können Sie ihn wie folgt konfigurieren:
{ "schematics": { "@schematics/angular:component": { "styleext": "less", "spec": false } } }
Dann können Sie ng g c direkt verwenden, um die entsprechenden Komponenten direkt zu generieren.
architect
enthält mehrere Sätze CLI-bezogener Projektautomatisierungsbefehlskonfigurationen, wie z. B. lokale Ausführung, Kompilierung, Tests usw. Standardmäßig sind mehrere Sätze von Befehlskonfigurationen voreingestellt, z. B. Build, Serve usw.:
{ "architect":{ "build":{}, "serve":{}, "extract-i18n":{}, "test":{}, "lint":{} } }
Konfigurationsattribute
Jedes Konfigurationselement verfügt über 3 Feldattribute: Builder, Optionen, Konfigurationen, wie z. B. die Standard-Build-Befehlskonfiguration:
{ "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 } } } } }
Dies ist die vom Projekt standardmäßig generierte Konfiguration.
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所指向的文件,里面详细地展示了各种字段的类型、配置以及描述说明。
Das obige ist der detaillierte Inhalt vonErläuterung der Datei „angular.json' (Codebeispiel). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!