Questa pagina è stata tradotta da PageTurner AI (beta). Non ufficialmente approvata dal progetto. Hai trovato un errore? Segnala problema →
Configurazione
La configurazione di Lerna è suddivisa in due file: lerna.json e nx.json.
Lerna.json
npmClient
È importante impostare questo valore se non stai utilizzando npm come gestore di pacchetti (ad esempio se usi yarn o pnpm), in modo che Lerna possa adattare parte della sua logica interna durante la risoluzione di configurazioni e pacchetti. Questo è particolarmente vero nel caso di pnpm perché utilizza un file separato pnpm-workspaces.yaml per definire la configurazione delle workspace.
packages
Per impostazione predefinita, Lerna tenterà di riutilizzare qualsiasi configurazione workspaces del tuo gestore di pacchetti. Se preferisci specificare un sottoinsieme dei pacchetti disponibili su cui Lerna deve operare, puoi utilizzare la proprietà packages che indica a Lerna dove cercare i file package.json.
{
"packages": ["packages/*"]
}
version
Lerna ha due modalità di pubblicazione dei pacchetti: fixed e independent. Nella modalità fixed, tutti i pacchetti interessati verranno pubblicati utilizzando la stessa versione. L'ultima versione pubblicata è registrata in lerna.json come segue:
{
"version": "1.2.0"
}
Nella modalità independent, ogni pacchetto ha una versione separata e lerna.json apparirà così:
{
"version": "independent"
}
Consulta la documentazione su versioning e pubblicazione per maggiori dettagli.
commands
Il file lerna.json può anche codificare opzioni per ogni comando in questo modo:
{
"command": {
"version": {
"allowBranch": "main",
"conventionalCommits": true
}
}
}
Trova le opzioni disponibili nella documentazione API.
Nx.json
NOTA: "{projectRoot}" e "{workspaceRoot}" sono sintassi speciali supportate dal task-runner, che verranno interpolate internamente durante l'esecuzione del comando. Non sostituire "{projectRoot}" o "{workspaceRoot}" con percorsi fissi poiché ciò riduce la flessibilità della configurazione.
{
"namedInputs": {
"default": ["{projectRoot}/**/*"],
"prod": ["!{projectRoot}/**/*.spec.tsx"]
},
"targetDefaults": {
"build": {
"dependsOn": ["prebuild", "^build"],
"inputs": ["prod", "^prod"],
"outputs": ["{projectRoot}/dist"],
"cache": true
},
"test": {
"inputs": ["default", "^prod", "{workspaceRoot}/jest.config.ts"],
"cache": true
}
}
}
Valori Predefiniti dei Target
I target corrispondono ai nomi degli script npm. Puoi aggiungere metadati associati, ad esempio, allo script di build di ogni progetto nel repository nella sezione targetDefaults.
cache
Quando impostato su true, indica a Nx di memorizzare nella cache i risultati dell'esecuzione dello script. Nella maggior parte dei repository, tutte le attività non di lunga durata (ad esempio non serve) dovrebbero essere memorizzabili.
dependsOn
I target possono dipendere da altri target. Uno scenario comune è la necessità di costruire prima le dipendenze di un progetto prima di costruire il progetto stesso. La proprietà dependsOn può essere utilizzata per definire le dipendenze di un singolo target.
"dependsOn": [ "prebuild", "^build"] indica a Nx che ogni script di build richiede prima l'esecuzione dello script prebuild dello stesso progetto e dello script build di tutte le dipendenze.
inputs & namedInputs
L'array inputs indica a Nx cosa considerare per determinare se una specifica esecuzione di uno script debba essere un cache hit o meno. Esistono tre tipi di input:
Fileset
Esempi:
-
{projectRoot}/**.*.ts -
equivalente a
{fileset: "{projectRoot}/**/*.ts"} -
{workspaceRoot}/jest.config.ts -
equivalente a
{fileset: "{workspaceRoot}/jest.config.ts}
Input Runtime
Esempi:
{runtime: "node -v"}
Nota: il valore risultante viene sottoposto a hashing e non viene mai visualizzato.
Variabili d'Ambiente
Esempi:
{env: "MY_ENV_VAR"}
Nota: il valore risultante viene sottoposto a hashing e non viene mai visualizzato.
Input Nominati
Esempi:
-
inputs: ["prod"] -
equivalente a
inputs: [{input: "prod", projects: "self"}]
Spesso lo stesso glob appare in più punti (es. il fileset "prod" escluderà i file di test per tutti i progetti). Mantenere sincronizzati questi elementi è soggetto a errori, quindi consigliamo di definire input nominati, che potrai poi richiamare in tutte le posizioni necessarie.
Utilizzo di ^
Esempi:
-
inputs: ["^prod"] -
equivalente a
inputs: [{input: "prod", projects: "dependencies"}]
Analogamente a dependsOn, il simbolo "^" indica le "dipendenze". È un concetto molto importante, illustriamolo con un esempio.
"test": {
"inputs": [ "default", "^prod" ]
}
La configurazione sopra indica che il target "test" dipende da tutti i file sorgente del progetto corrente e solo dalle sorgenti "prod" (non di test) delle sue dipendenze. In altre parole, tratta i sorgenti di test come privati. Se il tuo progetto remixapp dipende dalla libreria header, modificare i test di header non avrà alcun effetto sul target di test di remixapp.
outputs
"outputs": ["{projectRoot}/dist"] indica a Nx dove lo script di build creerà gli artefatti. Il valore fornito è quello predefinito, quindi in questo caso può essere omesso. "outputs": [] indica che il target di test non produce artefatti su disco. Puoi elencare quanti output desideri, usando anche glob o singoli file.
Questa configurazione di solito non è necessaria. Nx include valori predefiniti ragionevoli che implementano la configurazione sopra descritta.
Configurazione Specifica per Progetto
In molti workspace con progetti simili, nx.json contiene l'intera configurazione di Nx. Talvolta è utile avere una configurazione specifica per progetto, posizionata nel file package.json del progetto stesso.
{
"name": "parent",
"scripts": {
"build": "...",
"test": "..."
},
"dependencies": {...},
"nx": {
"namedInputs": {
"prod": [
"!{projectRoot}/**/*.test.tsx",
"{workspaceRoot}/configs/webpack.conf.js"
]
},
"targets": {
"build": {
"dependsOn": [
"^build"
],
"inputs": [
"prod",
"^prod"
],
"outputs": [
"{workspaceRoot}/dist/parent"
]
}
}
"implicitDependencies": ["projecta", "!projectb"]
}
}
Nota: gli namedInputs e targetDefaults definiti in nx.json sono semplicemente predefiniti. Se copiassi quella configurazione in ogni file package.json dei progetti, il risultato sarebbe identico.
In altre parole, ogni progetto ha un insieme di input nominati definito come: {...namedInputsFromNxJson, ...namedInputsFromProjectsPackageJson}. Le dipendenze dependsOn di ogni target/script sono definite come dependsOnFromProjectsPackageJson || dependsOnFromNxJson. Lo stesso vale per inputs e outputs.
inputs & namedInputs
Definire gli inputs per un target sostituisce l'insieme di input per quel nome di target definito in nx.json. In pseudocodice: inputs = packageJson.targets.build.inputs || nxJson.targetDefaults.build.inputs.
Puoi anche definire e ridefinire input nominati. Ciò abilita uno scenario d'uso chiave, dove il tuo nx.json può definire elementi come (applicabili a ogni progetto):
"test": {
"inputs": [
"default",
"^prod"
]
}
E i progetti possono definire il loro fileset "prod", senza dover ridefinire gli input per il target test.
{
"name": "parent",
"scripts": {
"build": "...",
"test": "..."
},
"dependencies": {...},
"nx": {
"namedInputs": {
"prod": [
"!{projectRoot}/**/*.test.js",
"{workspacRoot}/jest.config.js"
]
}
}
}
In questo caso Nx utilizzerà l'input prod corretto per ogni progetto.
dependsOn
Definire dependsOn per un target sostituisce dependsOn per quel nome di target definito in nx.json. In pseudocodice: dependsOn = packageJson.targets.build.dependsOn || nxJson.targetDefaults.build.dependsOn.
outputs
Definire outputs per un determinato target sostituirà gli outputs definiti per quel nome di target in nx.json.
Utilizzando pseudocodice: outputs = packageJson.targets.build.outputs || nxJson.targetDefaults.build.outputs.
Dipendenze implicite
La riga "implicitDependencies": ["projecta", "!projectb"] indica a Nx che il progetto genitore dipende da projecta anche
se non esiste alcuna dipendenza dichiarata nel suo package.json. Nx tratterà questa dipendenza allo stesso modo delle dipendenze
esplicite. Inoltre comunica a Nx che, nonostante esista una dipendenza esplicita su projectb, questa deve essere ignorata.
Configurazione aggiuntiva
Per ulteriori metodi di configurazione di task e caching, consulta la relativa documentazione Nx.