feat: add 'back/front end' in curriculum (#42596)
* chore: rename APIs and Microservices to include "Backend" (#42515) * fix typo * fix typo * undo change * Corrected grammar mistake Corrected a grammar mistake by removing a comma. * change APIs and Microservices cert title * update title * Change APIs and Microservices certi title * Update translations.json * update title * feat(curriculum): rename apis and microservices cert * rename folder structure * rename certificate * rename learn Markdown * apis-and-microservices -> back-end-development-and-apis * update backend meta * update i18n langs and cypress test Co-authored-by: Shaun Hamilton <shauhami020@gmail.com> * fix: add development to front-end libraries (#42512) * fix: added-the-word-Development-to-front-end-libraries * fix/added-the-word-Development-to-front-end-libraries * fix/added-word-development-to-front-end-libraries-in-other-related-files * fix/added-the-word-Development-to-front-end-and-all-related-files * fix/removed-typos-from-last-commit-in-index.md * fix/reverted-changes-that-i-made-to-dependecies * fix/removed xvfg * fix/reverted changes that i made to package.json * remove unwanted changes * front-end-development-libraries changes * rename backend certSlug and README * update i18n folder names and keys * test: add legacy path redirect tests This uses serve.json from the client-config repo, since we currently use that in production * fix: create public dir before moving serve.json * fix: add missing script * refactor: collect redirect tests * test: convert to cy.location for stricter tests * rename certificate folder to 00-certificates * change crowdin config to recognise new certificates location * allow translations to be used Co-authored-by: Nicholas Carrigan (he/him) <nhcarrigan@gmail.com> * add forwards slashes to path redirects * fix cypress path tests again * plese cypress * fix: test different challenge Okay so I literally have no idea why this one particular challenge fails in Cypress Firefox ONLY. Tom and I paired and spun a full build instance and confirmed in Firefox the page loads and redirects as expected. Changing to another bootstrap challenge passes Cypress firefox locally. Absolutely boggled by this. AAAAAAAAAAAAAAA * fix: separate the test Okay apparently the test does not work unless we separate it into a different `it` statement. >:( >:( >:( >:( Co-authored-by: Sujal Gupta <55016909+heysujal@users.noreply.github.com> Co-authored-by: Noor Fakhry <65724923+NoorFakhry@users.noreply.github.com> Co-authored-by: Oliver Eyton-Williams <ojeytonwilliams@gmail.com> Co-authored-by: Nicholas Carrigan (he/him) <nhcarrigan@gmail.com>
This commit is contained in:
Shaun Hamilton
GitHub
@ -0,0 +1,52 @@
|
||||
---
|
||||
id: 587d7fb3367417b2b2512bfc
|
||||
title: Aggiungere una descrizione al tuo package.json
|
||||
challengeType: 2
|
||||
forumTopicId: 301522
|
||||
dashedName: add-a-description-to-your-package-json
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
La parte successiva di un buon file package.json è il campo `description`, che conterrà una breve ma informativa descrizione del progetto.
|
||||
|
||||
Se un giorno avessi intenzione di pubblicare un pacchetto su npm, questa è la stringa che dovrebbe vendere la tua idea all'utente quando decide se installare o meno il pacchetto. Tuttavia, questo non è l'unico caso di utilizzo per la descrizione: essa è un ottimo modo per riassumere ciò che un progetto fa. È altrettanto importante in qualsiasi progetto Node.js per aiutare altri sviluppatori, futuri manutentori o anche il futuro te stesso a comprendere il progetto velocemente.
|
||||
|
||||
Indipendentemente da ciò che prevedi per il vostro progetto, una descrizione è sicuramente consigliata. Ecco un esempio:
|
||||
|
||||
```json
|
||||
"description": "A project that does something awesome",
|
||||
```
|
||||
|
||||
# --instructions--
|
||||
|
||||
Aggiungi una `description` al file package.json del tuo progetto.
|
||||
|
||||
**Nota:** Ricordati di usare le virgolette doppie (") per i nomi di campo e le virgole (,) per separare i campi.
|
||||
|
||||
# --hints--
|
||||
|
||||
package.json dovrebbe avere una chiave "description" valida
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert(packJson.description, '"description" is missing');
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
# --solutions--
|
||||
|
||||
```js
|
||||
/**
|
||||
Backend challenges don't need solutions,
|
||||
because they would need to be tested against a full working project.
|
||||
Please check our contributing guidelines to learn more.
|
||||
*/
|
||||
```
|
||||
@ -0,0 +1,48 @@
|
||||
---
|
||||
id: 587d7fb4367417b2b2512bfe
|
||||
title: Aggiungere una licenza al tuo package.json
|
||||
challengeType: 2
|
||||
forumTopicId: 301523
|
||||
dashedName: add-a-license-to-your-package-json
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Il campo `license` è dove informi gli utenti di quello che possono fare con il tuo progetto.
|
||||
|
||||
Alcune licenze comuni per progetti open source sono MIT e BSD. Le informazioni sulla licenza non sono richieste e le leggi sul copyright nella maggior parte dei paesi ti daranno la proprietà di ciò che crei senza che tu debba fare altro. Tuttavia, è sempre una buona pratica dichiarare esplicitamente quello che gli utenti possono e non possono fare. Ecco un esempio del campo di licenza:
|
||||
|
||||
```json
|
||||
"license": "MIT",
|
||||
```
|
||||
|
||||
# --instructions--
|
||||
|
||||
Compila il campo `license` nel file package.json del tuo progetto come ritieni opportuno.
|
||||
|
||||
# --hints--
|
||||
|
||||
package.json dovrebbe avere una chiave "license" valida
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert(packJson.license, '"license" is missing');
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
# --solutions--
|
||||
|
||||
```js
|
||||
/**
|
||||
Backend challenges don't need solutions,
|
||||
because they would need to be tested against a full working project.
|
||||
Please check our contributing guidelines to learn more.
|
||||
*/
|
||||
```
|
||||
@ -0,0 +1,46 @@
|
||||
---
|
||||
id: 587d7fb4367417b2b2512bff
|
||||
title: Aggiungere una versione al tuo package.json
|
||||
challengeType: 2
|
||||
forumTopicId: 301525
|
||||
dashedName: add-a-version-to-your-package-json
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
`version` è uno dei campi obbligatori del file package.json. Questo campo descrive la versione corrente del tuo progetto. Ecco un esempio:
|
||||
|
||||
```json
|
||||
"version": "1.2.0",
|
||||
```
|
||||
|
||||
# --instructions--
|
||||
|
||||
Aggiungi una `version` al file package.json del tuo progetto.
|
||||
|
||||
# --hints--
|
||||
|
||||
package.json deve avere una chiave "version" valida
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert(packJson.version, '"version" is missing');
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
# --solutions--
|
||||
|
||||
```js
|
||||
/**
|
||||
Backend challenges don't need solutions,
|
||||
because they would need to be tested against a full working project.
|
||||
Please check our contributing guidelines to learn more.
|
||||
*/
|
||||
```
|
||||
@ -0,0 +1,84 @@
|
||||
---
|
||||
id: 587d7fb4367417b2b2512bfd
|
||||
title: Aggiungere parole chiave al tuo package.json
|
||||
challengeType: 2
|
||||
forumTopicId: 301526
|
||||
dashedName: add-keywords-to-your-package-json
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Il campo `keywords` è dove puoi descrivere il tuo progetto usando le parole chiave correlate. Ecco un esempio:
|
||||
|
||||
```json
|
||||
"keywords": [ "descriptive", "related", "words" ],
|
||||
```
|
||||
|
||||
Come puoi vedere, questo campo è strutturato come una serie di stringhe tra virgolette doppie.
|
||||
|
||||
# --instructions--
|
||||
|
||||
Aggiungi un array di stringhe adatte al campo `keywords` nel file package.json del tuo progetto.
|
||||
|
||||
Una delle parole chiave dovrebbe essere "freecodecamp".
|
||||
|
||||
# --hints--
|
||||
|
||||
package.json dovrebbe avere una chiave "keywords" valida
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert(packJson.keywords, '"keywords" is missing');
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
il campo "keywords" dovrebbe essere un Array
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.isArray(packJson.keywords, '"keywords" is not an array');
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
"keywords" dovrebbe includere "freecodecamp"
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.include(
|
||||
packJson.keywords,
|
||||
'freecodecamp',
|
||||
'"keywords" does not include "freecodecamp"'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
# --solutions--
|
||||
|
||||
```js
|
||||
/**
|
||||
Backend challenges don't need solutions,
|
||||
because they would need to be tested against a full working project.
|
||||
Please check our contributing guidelines to learn more.
|
||||
*/
|
||||
```
|
||||
@ -0,0 +1,77 @@
|
||||
---
|
||||
id: 587d7fb4367417b2b2512c00
|
||||
title: Espandere il tuo progetto con pacchetti esterni di npm
|
||||
challengeType: 2
|
||||
forumTopicId: 301527
|
||||
dashedName: expand-your-project-with-external-packages-from-npm
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Uno dei più grandi motivi per utilizzare un gestore di pacchetti, è la loro potente gestione delle dipendenze. Invece di dover fare manualmente in modo di ottenere tutte le dipendenze ogni volta che si imposta un progetto su un nuovo computer, npm installa tutto per te automaticamente. Ma come può npm sapere esattamente di cosa ha bisogno il tuo progetto? Vai a vedere la sezione `dependencies` del tuo file package.json.
|
||||
|
||||
In questa sezione, i pacchetti richiesti dal progetto vengono memorizzati nel seguente formato:
|
||||
|
||||
```json
|
||||
"dependencies": {
|
||||
"package-name": "version",
|
||||
"express": "4.14.0"
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
# --instructions--
|
||||
|
||||
Aggiungi la versione "2.14.0" del pacchetto "moment" al campo `dependencies` del tuo file package.json.
|
||||
|
||||
**Nota:** Moment è una comoda libreria per lavorare con l'ora e le date.
|
||||
|
||||
# --hints--
|
||||
|
||||
"dependencies" dovrebbe includere "moment"
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.property(
|
||||
packJson.dependencies,
|
||||
'moment',
|
||||
'"dependencies" does not include "moment"'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
La versione di "moment" dovrebbe essere "2.14.0"
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.match(
|
||||
packJson.dependencies.moment,
|
||||
/^[\^\~]?2\.14\.0/,
|
||||
'Wrong version of "moment" installed. It should be 2.14.0'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
# --solutions--
|
||||
|
||||
```js
|
||||
/**
|
||||
Backend challenges don't need solutions,
|
||||
because they would need to be tested against a full working project.
|
||||
Please check our contributing guidelines to learn more.
|
||||
*/
|
||||
```
|
||||
@ -0,0 +1,60 @@
|
||||
---
|
||||
id: 587d7fb3367417b2b2512bfb
|
||||
title: 'Come utilizzare package.json, il nucleo di qualsiasi progetto Node.js o pacchetto npm'
|
||||
challengeType: 2
|
||||
forumTopicId: 301528
|
||||
dashedName: how-to-use-package-json-the-core-of-any-node-js-project-or-npm-package
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Lavorare su queste sfide ti porterà a scrivere il tuo codice utilizzando uno dei seguenti metodi:
|
||||
|
||||
- Clonare [questo repository GitHub](https://github.com/freeCodeCamp/boilerplate-npm/) e completare queste sfide localmente.
|
||||
- Usare [la nostra bozza di progetto su Replit](https://replit.com/github/freeCodeCamp/boilerplate-npm) per completare queste sfide.
|
||||
- Usare un costruttore di siti a tua scelta per completare il progetto. Assicurati di incorporare tutti i file dal nostro repository GitHub.
|
||||
|
||||
Quando hai finito, assicurati che una demo funzionante del tuo progetto sia ospitata pubblicamente da qualche parte. Quindi invia l'URL nel campo `Solution Link`. Facoltativamente, invia anche un link al codice sorgente del tuo progetto nel campo `GitHub Link`.
|
||||
|
||||
Il file `package.json` è il centro di qualsiasi progetto Node.js o pacchetto npm. Memorizza informazioni sul tuo progetto, in modo simile a come la sezione <head> di un documento HTML descrive il contenuto di una pagina web. Consiste di un singolo oggetto JSON dove le informazioni sono memorizzate in coppie chiave-valore. Ci sono solo due campi obbligatori; "name" e "version", ma è buona pratica fornire ulteriori informazioni sul tuo progetto che potrebbero essere utili per futuri utenti o manutentori.
|
||||
|
||||
Se guardi l'albero dei file del tuo progetto, troverai il file package.json al livello superiore dell'albero. Questo è il file che andremo a migliorare nelle prossime due sfide.
|
||||
|
||||
Una delle informazioni più comuni in questo file è il campo `author`. Specifica chi ha creato il progetto e può consistere in una stringa o un oggetto con informazioni di contatto o altri dettagli. Un oggetto è consigliato per progetti più grandi, ma una semplice stringa come l'esempio seguente farà al caso nostro per questo progetto.
|
||||
|
||||
```json
|
||||
"author": "Jane Doe",
|
||||
```
|
||||
|
||||
# --instructions--
|
||||
|
||||
Aggiungi il tuo nome come `author` del progetto nel file package.json.
|
||||
|
||||
**Nota:** Ricorda che stai scrivendo JSON, quindi tutti i nomi dei campi devono usare virgolette doppie (") ed essere separati con una virgola (,).
|
||||
|
||||
# --hints--
|
||||
|
||||
package.json deve avere una chiave "author" valida
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert(packJson.author, '"author" is missing');
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
# --solutions--
|
||||
|
||||
```js
|
||||
/**
|
||||
Backend challenges don't need solutions,
|
||||
because they would need to be tested against a full working project.
|
||||
Please check our contributing guidelines to learn more.
|
||||
*/
|
||||
```
|
||||
@ -0,0 +1,73 @@
|
||||
---
|
||||
id: 587d7fb5367417b2b2512c01
|
||||
title: Gestire le dipendenze npm comprendendo il versioning semantico
|
||||
challengeType: 2
|
||||
forumTopicId: 301529
|
||||
dashedName: manage-npm-dependencies-by-understanding-semantic-versioning
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Il campo `versions` nella sezione delle dipendenze del tuo pacchetto npm segue quello che si chiama Versioning Semantico (SemVer), uno standard di settore per la versione del software al fine di rendere più facile la gestione delle dipendenze. Le librerie, i framework o altri strumenti pubblicati su npm dovrebbero utilizzare SemVer per comunicare chiaramente che tipo di cambiamenti i progetti possono aspettarsi se essi vengono aggiornati.
|
||||
|
||||
Conoscere SemVer può essere utile quando si sviluppa un software che utilizza dipendenze esterne (cosa che avviene quasi sempre). Un giorno, la tua comprensione di questi numeri ti salverà dall'introduzione accidentale di cambiamenti che potrebbero bloccare il tuo progetto senza capire perché le cose che hanno funzionato fino a ieri improvvisamente non funzionano più oggi. Questo è come il Semantic Versioning funziona secondo il sito ufficiale:
|
||||
|
||||
```json
|
||||
"package": "MAJOR.MINOR.PATCH"
|
||||
```
|
||||
|
||||
La versione MAJOR dovrebbe essere incrementata quando si effettuano modifiche API incompatibili. La versione MINOR dovrebbe essere incrementata quando si aggiungono funzionalità in modo retrocompatibile. La versione PATCH dovrebbe essere incrementata quando si fanno correzioni di bug retrocompatibili. Ciò significa che le PATCHes sono correzioni di bug e le MINOR aggiungono nuove funzionalità, ma nessuna delle due rischia di rompere quello che funzionava prima. Infine, le MAJORs aggiungono modifiche che non funzioneranno con le versioni precedenti.
|
||||
|
||||
# --instructions--
|
||||
|
||||
Nella sezione dependencies del tuo file package.json, cambia la `version` di moment per farlo corrispondere alla versione MAJOR 2, alla versione MINOR 10 e alla versione PATCH 2
|
||||
|
||||
# --hints--
|
||||
|
||||
"dependencies" dovrebbe includere "moment"
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.property(
|
||||
packJson.dependencies,
|
||||
'moment',
|
||||
'"dependencies" does not include "moment"'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
La versione di "moment" dovrebbe essere "2.10.2"
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.equal(
|
||||
packJson.dependencies.moment,
|
||||
'2.10.2',
|
||||
'Wrong version of "moment". It should be 2.10.2'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
# --solutions--
|
||||
|
||||
```js
|
||||
/**
|
||||
Backend challenges don't need solutions,
|
||||
because they would need to be tested against a full working project.
|
||||
Please check our contributing guidelines to learn more.
|
||||
*/
|
||||
```
|
||||
@ -0,0 +1,52 @@
|
||||
---
|
||||
id: 587d7fb5367417b2b2512c04
|
||||
title: Rimuovere un pacchetto dalle tue dipendenze
|
||||
challengeType: 2
|
||||
forumTopicId: 301530
|
||||
dashedName: remove-a-package-from-your-dependencies
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Ora hai testato alcuni modi per gestire le dipendenze del tuo progetto utilizzando la sezione delle dipendenze di package.json. Hai anche incluso dei pacchetti esterni aggiungendoli al file e hai detto a npm quali tipi di versioni desideri, utilizzando caratteri speciali come la tilde o il cursore.
|
||||
|
||||
Ma cosa dovresti fare per rimuovere un pacchetto esterno di cui non hai più bisogno? Potresti già averlo indovinato, basta rimuovere dalle dipendenze la coppia chiave-valore corrispondente a quel pacchetto.
|
||||
|
||||
Questo stesso metodo si applica anche alla rimozione di altri campi nel tuo package.json
|
||||
|
||||
# --instructions--
|
||||
|
||||
Rimuovi il pacchetto moment dalle tue dipendenze.
|
||||
|
||||
**Nota:** Assicurati di avere la giusta quantità di virgole dopo averlo rimosso.
|
||||
|
||||
# --hints--
|
||||
|
||||
"dependencies" non dovrebbe includere "moment"
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.notProperty(
|
||||
packJson.dependencies,
|
||||
'moment',
|
||||
'"dependencies" still includes "moment"'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
# --solutions--
|
||||
|
||||
```js
|
||||
/**
|
||||
Backend challenges don't need solutions,
|
||||
because they would need to be tested against a full working project.
|
||||
Please check our contributing guidelines to learn more.
|
||||
*/
|
||||
```
|
||||
@ -0,0 +1,75 @@
|
||||
---
|
||||
id: 587d7fb5367417b2b2512c03
|
||||
title: Usare il simbolo del cursore per specificare l'ultima versione minore di una dipendenza
|
||||
challengeType: 2
|
||||
forumTopicId: 301531
|
||||
dashedName: use-the-caret-character-to-use-the-latest-minor-version-of-a-dependency
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Simile a come la tilde che abbiamo imparato nell'ultima sfida permette a npm di installare l'ultima PATCH per una dipendenza, il cursore (caret, `^`) permette a npm di installare anche aggiornamenti futuri. La differenza è che il cursore permetterà sia gli aggiornamenti MINOR che le PATCHes.
|
||||
|
||||
La tua versione attuale di moment dovrebbe essere "~2.10.2" che permette a npm di installare l'ultima versione 2.10.x. Se invece dovessi usare il cursore (^) come prefisso di versione, npm avrebbe il permesso di aggiornare a qualsiasi versione 2.x.x.
|
||||
|
||||
```json
|
||||
"package": "^1.3.8"
|
||||
```
|
||||
|
||||
Questo permetterebbe di aggiornare qualsiasi versione 1.x.x del pacchetto.
|
||||
|
||||
# --instructions--
|
||||
|
||||
Usa il cursore (`^`) per prefissare la versione di moment nelle tue dipendenze e consentire a npm di aggiornarlo a qualsiasi nuova versione MINOR.
|
||||
|
||||
**Nota:** I numeri di versione non devono essere modificati.
|
||||
|
||||
# --hints--
|
||||
|
||||
"dependencies" dovrebbe includere "moment"
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.property(
|
||||
packJson.dependencies,
|
||||
'moment',
|
||||
'"dependencies" does not include "moment"'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
La versione di "moment" dovrebbe corrispondere a "^2.x.x"
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.match(
|
||||
packJson.dependencies.moment,
|
||||
/^\^2\./,
|
||||
'Wrong version of "moment". It should be ^2.10.2'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
# --solutions--
|
||||
|
||||
```js
|
||||
/**
|
||||
Backend challenges don't need solutions,
|
||||
because they would need to be tested against a full working project.
|
||||
Please check our contributing guidelines to learn more.
|
||||
*/
|
||||
```
|
||||
@ -0,0 +1,75 @@
|
||||
---
|
||||
id: 587d7fb5367417b2b2512c02
|
||||
title: Usare il carattere tilde per utilizzare sempre l'ultima versione patch di una dipendenza
|
||||
challengeType: 2
|
||||
forumTopicId: 301532
|
||||
dashedName: use-the-tilde-character-to-always-use-the-latest-patch-version-of-a-dependency
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Nell'ultima sfida, hai detto a npm di includere solo una versione specifica di un pacchetto. Questo è un modo utile per congelare le tue dipendenze, se hai bisogno di assicurarti che diverse parti del tuo progetto rimangano compatibili tra loro. Ma nella maggior parte dei casi d'uso, non vuoi perdere le correzioni di bug dal momento che spesso includono importanti patch di sicurezza e (si spera) non rompono le cose nel farlo.
|
||||
|
||||
Per consentire a una dipendenza npm di aggiornare all'ultima versione PATCH, è possibile prefissare la versione della dipendenza con il carattere tilde (`~`). Ecco un esempio di come consentire gli aggiornamenti di qualsiasi versione 1.3.x.
|
||||
|
||||
```json
|
||||
"package": "~1.3.8"
|
||||
```
|
||||
|
||||
# --instructions--
|
||||
|
||||
Nel file package.json, la tua regola corrente per come npm potrebbe aggiornare moment è usare una versione specifica (2.10.2). Ma ora desideriamo consentire l'ultima versione 2.10.x.
|
||||
|
||||
Usa il carattere tilde (`~`) per prefissare la versione di moment nelle tue dipendenze, e consentire a npm di aggiornarlo a qualsiasi nuova release PATCH.
|
||||
|
||||
**Nota:** I numeri di versione non devono essere modificati.
|
||||
|
||||
# --hints--
|
||||
|
||||
"dependencies" dovrebbe includere "moment"
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.property(
|
||||
packJson.dependencies,
|
||||
'moment',
|
||||
'"dependencies" does not include "moment"'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
La versione di "moment" dovrebbe corrispondere a "~2.10.2"
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.match(
|
||||
packJson.dependencies.moment,
|
||||
/^\~2\.10\.2/,
|
||||
'Wrong version of "moment". It should be ~2.10.2'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
# --solutions--
|
||||
|
||||
```js
|
||||
/**
|
||||
Backend challenges don't need solutions,
|
||||
because they would need to be tested against a full working project.
|
||||
Please check our contributing guidelines to learn more.
|
||||
*/
|
||||
```
|
||||
Reference in New Issue
Block a user