casraf/DefinitelyTyped
1
0
Fork 0
mirror of https://github.com/chenasraf/DefinitelyTyped.git synced 2026-05-18 01:49:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix some typos in README.it.md (#65568)

Browse Source
This commit is contained in:
Federico Bucchi
2023-05-24 13:29:19 -07:00
committed by GitHub
parent 3e1ebdd18f
commit f8d973bee4
1 changed files with 13 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
README.it.md
View File

@@ -33,7 +33,7 @@ Ad esempio:
npm install --save-dev @types/node
```
I tipi dovrebbero poi essere inclusi automaticamente dal complilatore.
I tipi dovrebbero poi essere inclusi automaticamente dal compilatore.
Potresti dover aggiungere una `types` reference se non stai usando i moduli:
```ts
@@ -49,11 +49,11 @@ Se ancora non riesci a trovarlo, vuol dire che sono [inclusi](https://www.typesc
Di solito vengono specificati nel campo `"types"` o `"typings"` nel `package.json`;
oppure prova a cercare per dei file ".d.ts" nel package ed includerli manualmente con `/// <reference path="" />`.
#### Vecchie vesioni di TypeScript (4.0 e precedenti)
#### Vecchie versioni di TypeScript (4.0 e precedenti)
"Definitely Typed" testa packages solo su versioni di TypeScript che hanno meno di due anni.
Attualmente vengono testate le versioni 4.1 e successive.
Se stai usando una versiond di TypeScript tra 2.0 e la 4.0, puoi ancora provare ad installare i package `@types`, in quanto la maggior parte di questi non usano le funzionalità più all'avanguardia di Typescript.
Se stai usando una versione di TypeScript tra 2.0 e la 4.0, puoi ancora provare ad installare i package `@types`, in quanto la maggior parte di questi non usano le funzionalità più all'avanguardia di Typescript.
Non c'è comunque nessuna garanzia che funzioneranno.
Di seguito la finestra di supporto per ogni versione di TypeScript:
@@ -89,7 +89,6 @@ Potresti dover aggiungere manualmente le [reference](https://www.typescriptlang.
Prima di condividere il tuo miglioramento col mondo intero, utilizza i tipi tu stesso attraverso la creazione del file `typename.d.ts` nel tuo progetto per poi riempire il suo export:
```ts
declare module "libname" {
// Types inside here
@@ -99,7 +98,7 @@ declare module "libname" {
#### Test per la modifica di un package già esistente
Puoi modificare i tipi direttamente in `node_modules/@types/foo/index.d.ts` per verificare i tuoi cambiamenti, successivamente puoi portare questi cambiamenti a questa repository attraverso gli step descritto qui sotto.
Puoi modificare i tipi direttamente in `node_modules/@types/foo/index.d.ts` per verificare i tuoi cambiamenti, successivamente puoi portare questi cambiamenti a questa repository attraverso gli step descritti qui sotto.
In alternativa puoi usare [module augmentation](https://www.typescriptlang.org/docs/handbook/declaration-merging.html#module-augmentation) per estendere i tipi esistenti del modulo DT oppure usare la tecnica `declare module` qui sopra che andrà a sovrascrivere la versione presente nei `node_modules`.
@@ -309,7 +308,7 @@ Riassunto: `esModuleInterop` e `allowSyntheticDefaultImports` *non sono permessi
> import Component from "./component";
> ```
>
> Siccome la valdità durante la compilazione dell'import in `index.d.ts` dipende da specifiche impostazioni di compilazione, che gli utenti che utilizzeranno i tuoi tipi non avranno, un utilizzo di questa modalità in DefinitelyTyped obbligherebbe gli utenti a modificare le loro impostazioni di compilazione, che potrebbero essere incorrette per il loro runtime. Invece, devi scrivere un import CJS per un export CJS per garantire una compatibilità diffondibile e indipendente da configurazioni specifiche:
> Siccome la validità durante la compilazione dell'import in `index.d.ts` dipende da specifiche impostazioni di compilazione, che gli utenti che utilizzeranno i tuoi tipi non avranno, un utilizzo di questa modalità in DefinitelyTyped obbligherebbe gli utenti a modificare le loro impostazioni di compilazione, che potrebbero essere incorrette per il loro runtime. Invece, devi scrivere un import CJS per un export CJS per garantire una compatibilità diffondibile e indipendente da configurazioni specifiche:
>
> ```ts
> // index.d.ts
@@ -322,10 +321,10 @@ Riassunto: `esModuleInterop` e `allowSyntheticDefaultImports` *non sono permessi
Solitamente non ne avrai bisogno.
Un `package.json` potrebbe essere incluso per specificare le dipendenze che non sono altri `@types` package.
[Pikaday ne è un buon esempio](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/pikaday/package.json).
Anche se stai scrivendo un tuo `package.json`, upoi solo specificare dipendenze; altri campi come `"description"` non sono consentiti.
Puotresti anche aver bisogno di aggiungere una dipendenza alla [lista dei package consentiti](https://github.com/microsoft/DefinitelyTyped-tools/blob/master/packages/definitions-parser/allowedPackageJsonDependencies.txt).
Anche se stai scrivendo un tuo `package.json`, puoi solo specificare dipendenze; altri campi come `"description"` non sono consentiti.
Potresti anche aver bisogno di aggiungere una dipendenza alla [lista dei package consentiti](https://github.com/microsoft/DefinitelyTyped-tools/blob/master/packages/definitions-parser/allowedPackageJsonDependencies.txt).
Questa lista è aggiornata da persone, che ci danno l'opportunità di assicurarci che i package `@types` non dipendono da package rischiosi.
Nel raro caso in cui un package `@types` viene eliminato a favore dei tipi inclusi nel package npm analogo E avessi bisogno di dipendere dal vecchio package `@types`, puoi aggiungere una dipendenza ad un package `@types`.
Nel raro caso in cui un package `@types` viene eliminato a favore dei tipi inclusi nel package npm analogo e avessi bisogno di dipendere dal vecchio package `@types`, puoi aggiungere una dipendenza ad un package `@types`.
Assicurati di spiegare tutto ciò quando lo aggiungi alla lista dei package consentiti cosicchè gli altri possano capire cosa stai facendo.
#### `OTHER_FILES.txt`
@@ -462,7 +461,7 @@ Per un package npm, `export =` è apposita se `node -p 'require("foo")'` funzion
#### Voglio usare le funzionalità delle versioni più nuove di Typescript
Allora devi aggiungere un commento all'ultima riga del tuo header di definizione (dopo `// Definitions: https://github.com/DefinitelyTyped/DefinitelyTyped`): `// Minimum TypeScript Version: X.Y`. Ciò specifichera la versione minima supportata.
Allora devi aggiungere un commento all'ultima riga del tuo header di definizione (dopo `// Definitions: https://github.com/DefinitelyTyped/DefinitelyTyped`): `// Minimum TypeScript Version: X.Y`. Ciò specificherà la versione minima supportata.
In ogni caso, se il tuo progetto avesse bisogno di mantenere tipi compatibili con, ad esempio, versioni 3.7 e successive ed **allo stesso tempo** vesioni 3.6 o precedenti, dovrai usare la funzionalità `typesVersions`.
Puoi trovare una spiegazione nel dettaglio di questa funzionalità nella [documentazione ufficiale di Typescript](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-1.html#version-selection-with-typesversions).
@@ -482,7 +481,7 @@ Ecco qui un breve esempio per iniziare:
```
2. Crea la sottocartella menzionata dal campo `typesVersions` dentro la tua cartella dei tipi (che nel nostro esempio è `ts3.6/`).
`ts3.6/` suppporterà le versioni uguali od inferiori alla 3.6, quindi copia i tipi esistenti con i test lì.
`ts3.6/` suppporterà le versioni uguali o inferiori alla 3.6, quindi copia i tipi esistenti con i test lì.
Dovrai eliminare l'header delle definizioni da `ts3.6/index.d.ts` dal momento che solo la root `index.d.ts` può averlo.
@@ -551,11 +550,11 @@ Ad esempio, se ad una libreria viene rimossa una funzione che esporta e la sua u
Inoltre, quando questa nuova versione `4.0.0` viene pubblicata, la versione del suo pacchetto di dichiarazione dei tipi dev'essere anch'esso aggiornato alla `4.0.0`, modificandone ovviamente le dichiarazioni in modo che riflettano le modifiche sostanziali della nuova versione.
Molte librerie hanno un vasto numero di utenti che le utilizzano (compresi mantenitori di altri pacchetti che usano la libreria come dipendenza) e che probabilimente non passeranno subito alla nuova versione major. Questo perchè potrebbero volerci mesi prima che il mantenitore trovi il tempo per adattare il codice alle nuove modifiche della libreria.
Nel frattempo, utenti che usano la vecchia versione della libreria potrebbero richiedere aggiornamenti per la vecchia versione delle dichiarazioni dei tipi, ad esempio nel caso in cui un utente che usa la vecchia versione della libreria trova un erroore nelle definizioni dei tipi.
Nel frattempo, utenti che usano la vecchia versione della libreria potrebbero richiedere aggiornamenti per la vecchia versione delle dichiarazioni dei tipi, ad esempio nel caso in cui un utente che usa la vecchia versione della libreria trova un errore nelle definizioni dei tipi.
Se hai intenzione di continuare a mantenere ed aggiornare le dichiarazioni dei tipi per le vecchie versioni di una libreria, puoi creare una sottocartella (es. `/v2/`) chiamata come la versione che presto diventerà vecchia e copiarci dentro tutte le dichiarazioni attuali.
Siccome la cartella principale deve sempre contenere le dichiarazioni dei tipi per la versione più nuova, avrai anche bisogno di fare alcune modifiche alle dichiarazioni della vecchia versione che ora sta nella sottocartella, per essere sicuro che gli eventuali indirizzi relativi siano riferiti alla sottocartella e non più alla cartella principale.
Siccome la cartella principale deve sempre contenere le dichiarazioni dei tipi per la versione più nuova, avrai anche bisogno di fare alcune modifiche alle dichiarazioni della vecchia versione che ora sta nella sottocartella, per essere sicuro che gli eventuali indirizzi relativi siano riferiti alla sottocartella e non più alla cartella principale.
1. Aggiorna gli indirizzi relativi nel `tsconfig.json` ed in un eventuale `tslint.json`.
2. Aggiungi delle regole per mappare gli indirizzi cosicchè i test vengano eseguiti per la versione voluta.
@@ -591,7 +590,7 @@ Nota che `/// <reference types=".." />` non funziona con il mapping degli indiri
La guida di Typescript spiega benissimo [come scrivere le definizioni dei tipi](https://www.typescriptlang.org/docs/handbook/declaration-files/introduction.html) ed ha anche [un file di esempio](https://www.typescriptlang.org/docs/handbook/declaration-files/templates/global-modifying-module-d-ts.html) che è esattamente una libreria che può essere usata sia come modulo su nodejs che come libreria globale in una pagina web.
Per accertarti che le tue definizioni possono essere usate sia globalmente che che modulo importato, crea una cartella `test` e creaci dentro due file di test.
Per accertarti che le tue definizioni possono essere usate sia globalmente che come modulo importato, crea una cartella `test` e creaci dentro due file di test.
Chiamane uno `NomeLibreria-global.test.ts` e l'altro `NomeLibreria-module.test.ts`.
Il file di test *global* dovrebbe controllare che le definizioni funzionano bene quando la libreria è usata globalmente in una pagina web (in questo caso non devi specificare un `import`).
Il file di test *module*, invece, controlla se le definzioni funzionano quando la libreria viene importata come un modulo.