Käytännön opas JavaScriptin ja TypeScriptin muuntimen käyttöön
Valmis siirtymään? Tämä opas käsittelee JavaScriptistä TypeScriptiin muuntimen käyttöä, strategista suunnittelua ja turvallista refaktorointia sujuvan siirtymän varmistamiseksi.

JavaScriptista TypeScriptiin muuntaja on käytännössä älykäs skripti, joka automatisoi siirtymisen ensimmäiset työläät vaiheet. Se ottaa olemassa olevat JavaScript-tiedostosi ja kääntää ne TypeScript-syntaksiksi, mikä säästää sinulta paljon aikaa alussa. Nämä työkalut hoitavat raskaan työn, kuten tiedostojen nimeämisen .js:stä .ts:ksi tai .tsx:ksi ja perus any -tyyppien lisäämisen, mikä luo pohjan myöhemmälle hienovaraisemmalle, manuaaliselle refaktoroinnille.
Miksi tiimit siirtyvät JavaScriptista TypeScriptiin
Siirtyminen JavaScriptista TypeScriptiin ei ole vain trendi; se on strateginen muutos siinä, miten tiimit rakentavat ohjelmistoja, jotka on tarkoitettu kestämään. Vaikka pääominaisuus on staattisten tyyppien lisääminen dynaamiseen kieleen, todellinen arvo ulottuu paljon syvemmälle. Se vaikuttaa kaikkeen virheiden varhaiseen havaitsemiseen, yhteistyön sujuvuuteen ja varmistamiseen, että projekti voidaan ylläpitää vuosia eteenpäin. Tässä ei ole kyse uusimman teknologian omaksumisesta sen itsensä vuoksi—on kyse kestävämpien sovellusten rakentamisesta tehokkaammin.
Välitön etu on virheiden havaitseminen koodatessasi, ei sen jälkeen kun olet julkaissut tuotantoon. JavaScript on tunnetusti joustava, mikä tarkoittaa myös, että on helppo tehdä yksinkertaisia virheitä, kuten kirjoitusvirheitä objektin ominaisuuksissa tai antaa numero siellä, missä merkkijonoa odotettiin. TypeScriptin kääntäjä toimii aina päällä olevana linterinä, joka merkitsee nämä ongelmat suoraan editorissasi ennen kuin edes suoritat koodin.
Ohjelmoijan itseluottamuksen lisääminen ja monimutkaisen koodin hallinta
Kun koodipohja laajenee, kaiken yhdistelemisen seuraaminen muuttuu kokopäiväiseksi työksi. Suuressa JavaScript-projektissa löydät usein itsesi kaivamasta tiedostoja tai ripottelemasta console.log -lausuntoja joka puolelle vain selvittääksesi, miltä objekti näyttää tai mitä funktio palauttaa. Tämä henkinen kuormitus hidastaa kaikkia ja tekee uusien virheiden tuomisesta liian helppoa.
TypeScript kääntää tämän täysin päälaelleen tekemällä koodista oman dokumentaationsa.
- Selkeät sopimukset: Kun käytät rajapintaa tai tyyppialias, luot selkeän, eksplisiittisen sopimuksen. Ei ole arvailua siitä, mitä tietoa funktio tarvitsee tai miltä objekti näyttää.
- Tehostetut työkalut: Koodieditoristasi tulee yhtäkkiä paljon älykkäämpi. Saat älykästä automaattista täydennystä, välittömiä varoituksia tyyppivirheistä ja refaktorointityökaluja, jotka toimivat luotettavasti.
- Yksinkertaisempi perehdytys: Uudet kehittäjät voivat päästä vauhtiin paljon nopeammin. Sen sijaan, että heidän pitäisi etsiä vanhempaa kehittäjää vastauksia varten, he voivat vain katsoa tyyppejä ymmärtääkseen kentän rakenteen.
Tämä siirtyminen kohti rakenteellista, tyyppiturvallista koodia ei ole vain niche-mieltymys. Se on laaja teollisuuden muutos, jota tukevat todelliset, mitattavissa olevat parannukset koodin laadussa ja tiimien tuottavuudessa.
Numerot eivät valehtele
TypeScriptin suosion kasvu on ollut hämmästyttävää. NPM-lataukset kääntäjälle nousivat 60 miljoonaan viikossa vuoden 2025 alussa—valtava hyppy vain 20 miljoonasta viikoittaisesta latauksesta vuonna 2021. Tämä trendi on vieläkin voimakkaampi suuremmissa yrityksissä, joissa käyttöönotto on kasvanut yli 400% vuodesta 2020.
Suuret toimijat kuten Slack, Microsoft ja Shopify ovat kaikki investoineet voimakkaasti valtavien koodipohjien siirtämiseen. He lyövät vetoa TypeScriptin tuoman vakauden ja selkeyden puolesta. Voit tutkia lisää tietoa TypeScriptin vaikuttavasta kasvusta ja käyttöönottoasteista nähdäksesi, kuinka laajalle tämä liike on levinnyt. Tämä ei ole muoti-ilmiö; se on taisteltu strategia paremman ohjelmiston rakentamiseksi suuressa mittakaavassa.
Siirtymisen pelisuunnitelman laatiminen
Koodipohjan siirtymiseen hyppääminen ilman kunnollista suunnitelmaa on resepti katastrofiin. Se on kuin yrittäisi navigoida uudessa kaupungissa ilman karttaa—hukkaan, turhaudut ja hukkaat valtavasti aikaa. Hyvin mietitty pelisuunnitelma on suurin tekijä, joka erottaa sujuvan siirtymisen kaoottisesta sekasorrosta. Se on tiekarttasi, joka ohjaa jokaista päätöstä siitä, mistä aloittaa ja miten käsittelet väistämättömät haasteet.
Ennen kuin edes ajattelet tiedostopäivityksen muuttamista, sinun on saatava käsitys maastosta. Perusteellinen tarkastus JavaScript-koodipohjastasi on ehdoton. Millainen rakenne on? Kuinka monimutkaisia eri moduulit ovat? Mitkä ovat riippuvuudet? Aloita kartoittamalla projektisi riippuvuuskartta nähdäksesi, miten kaikki liittyy toisiinsa. Tämä näyttää heti, mitkä perustavanlaatuiset osat on käsiteltävä ensin—ne, joilla on vähiten riippuvuuksia muista.
Siirtymisstrategian valitseminen
Kun sinulla on selkeä kuva koodipohjastasi, kohtaat ensimmäisen suuren haaran tiellä. Repäisetkö laastarin irti ja muunnatko kaiken kerralla ("big bang"), vai otatko hitaamman, systemaattisemman lähestymistavan, tiedosto kerrallaan? Molemmilla on vakavia etuja ja haittoja.
- Big-Bang: Tässä vaiheessa vapautat
javascript to typescript converterin tai codemodin koko koodipohjalle yhdessä massiivisessa työntöliikkeessä. Se on nopeaa, ja vältät sekavan JS/TS-ympäristön ylläpidon päänsärkyä. Mutta se on myös uskomattoman häiritsevää ja voi pysäyttää kaiken muun ominaisuuden kehittämisen. Tämä strategia on yleensä vain toteuttamiskelpoinen suurille yrityksille, kuten Pinterestille, jotka voivat omistaa koko tiimin ponnistukseen. - Vähittäinen siirtyminen: Tämä on yleisempi, tiedosto kerrallaan lähestymistapa. Se on paljon vähemmän häiritsevää ja antaa tiimillesi mahdollisuuden oppia TypeScriptiä matkan varrella. Asettamalla
"allowJs": truetiedostossasitsconfig.jsonvoit antaa vanhojen.js-tiedostojen ja uusien.ts-tiedostojen elää yhdessä harmoniassa. Tämä on lähes aina käytännöllisempi valinta tiimeille, jotka eivät voi pysäyttää kaikkea.
Tässä ei ole yhtä oikeaa vastausta. Kaikki riippuu tiimisi koosta, projektisi nopeudesta ja siitä, kuinka paljon riskiä olet valmis ottamaan.
Vähittäinen siirtyminen on turvallisempaa, mutta big-bang-menetelmä vie sinut maaliin paljon nopeammin.
Tämä kaavio todella tiivistää ydinsyyt miksi teet tätä, mikä on ratkaisevan tärkeää tiimin motivoimiseksi.

Nämä tavoitteet – vähemmän virheitä, parempi yhteistyö ja tulevaisuuden kestävyys – keskiössä muistuttaa kaikkia siitä, miksi siirtymisen väliaikainen tuska on sen arvoista.
Perustan Luominen Menestykselle
Kun lähestymistapa on lukittu, on aika laatia perussäännöt. Tämän vaiheen ohittaminen on klassinen virhe, joka johtaa loputtomiin väittelyihin ja epäjohdonmukaisuuksiin myöhemmin.
Ensinnäkin, saa tiimisi sopimaan koodauskonventioista. Käytätkö interface vai type? Mitä mieltä olet any tyypistä? Onko se kielletty, vai sallittu väliaikaisena pakokeinona? Kirjoita nämä päätökset tyyliohjeeseen. Johdonmukaisuus tässä on valtava voitto tiimisi kehittäjätuottavuudelle.
Seuraavaksi, luo alkuperäinen tsconfig.json tiedosto. Avain tässä on aloittaa löysillä, anteeksiantavilla asetuksilla. Jos otat kaikki tiukkuustarkistukset käyttöön heti alusta alkaen, hukutat tiimisi tuhansiin virheisiin.
Tässä on muutamia järkeviä oletusasetuksia aloittamiseen:
tsconfig.json Vaihtoehto |
Suositeltu Alkuperäinen Asetus | Syynä |
|---|---|---|
"noImplicitAny" |
false |
Tämä estää kääntäjää huutamasta sinulle, kun se ei voi selvittää tyyppiä itse. |
"strictNullChecks" |
false |
Pelastat itsesi virheiden tulvasta, joka liittyy null ja undefined vanhassa koodissasi. |
"allowJs" |
true |
Tämä on taikakytkin, joka sallii JS- ja TS-tiedostojen tuoda toisiaan, mikä mahdollistaa vähittäisen siirtymisen. |
Lopuksi, määrittele tärkeimmät tyypit käsin. Ennen kuin käytät mitään automatisoituja työkaluja, istu alas ja tunnista sovelluksesi ydintietorakenteet – asioita kuten User, Product tai Session. TypeScript-rajapintojen manuaalinen kirjoittaminen näille varmistaa, että koodipohjasi tärkeimmät osat ovat tyypitetty oikein heti alusta alkaen, mikä antaa sinulle vankan perustan rakentaa.
3. Automaattisten Työkalujen Käyttö Raskaaseen Työhön
Olkaamme rehellisiä: tuhansien tiedostojen manuaalinen muuntaminen JavaScriptistä TypeScriptiin on varma tie loppuunpalamiseen. Tässä automaattiset työkalut tulevat apuun. Ajattele niitä väsymättömänä assistenttina, joka hoitaa siirtymisen kaikkein tylsimmät ja toistuvat osat. Hyvä javascript to typescript converter hoitaa raskaan työn, vapauttaen tiimisi keskittymään siihen, mikä on tärkeää – tyyppien hienosäätöön ja varsinaisen koodin laadun parantamiseen.

Nämä työkalut eivät ole hopealuoti, mutta ne ovat valtava kiihdyttävä tekijä. Ne käyvät läpi koodipohjasi ja suorittavat ensimmäisen vaiheen olennaisia muunnoksia, kuten:
- Tiedostojen Nimeäminen: Vaihtamalla tiedostopäätteet
.jstai.jsxpäätteiksi.tstai.tsx. - Alkuperäinen Tyypitys: Lisäämällä
anytyypin sinne, missä työkalu ei voi päätellä tiettyä tyyppiä. Tämä on ratkaisevan tärkeää, koska se saa koodisi käännettävään tilaan heti. - Syntaksin Päivitykset: Muuntamalla yleisiä JavaScript-malleja, kuten
PropTypesReactissa, niiden TypeScript-vastaaviksi.
Tämä ensimmäinen automatisoitu vaihe luo "ensimmäisen luonnoksen" uudesta TypeScript-koodipohjastasi. Se ei tule olemaan kaunis, mutta se on voimassa oleva, käännettävä lähtökohta, joka voi säästää sinulta satoja tunteja mielettömän manuaalisen työn tekemiseltä.
Ensimmäinen Kierros Codemodien ja Muuntimien Kanssa
Kun on kyse automatisoidusta siirtymisestä, kuulet paljon codemodeista. Nämä ovat skriptejä, jotka ohjelmallisesti refaktoroivat koodiasi. Yksi parhaista työkaluista tähän työhön on ts-migrate, joka avattiin lähdekoodina Airbnb:n oman suuren siirtymisen jälkeen.
Aloittaminen on usein yhtä yksinkertaista kuin yhden komennon suorittaminen projektisi juurihakemistossa. Esimerkiksi ensimmäinen looginen askel on yleensä tiedostojen nimeäminen.
ts-migrate rename komento tekee juuri niin:npx ts-migrate rename .
Tämä komento käy läpi projektisi, muuttaen kaikki .js ja .jsx tiedostot niiden .ts ja .tsx vastineiksi.
Tämän jälkeen voit käyttää työkalupakin muita codemodeja aloittaaksesi tyyppien täyttämisen ja yleisten syntaksiongelmien korjaamisen, jolloin voit purkaa koodipohjaa pala palalta.
Keskeinen oppimispiste: Automatisoinnin tarkoitus ei ole saavuttaa täydellistä, tuotantovalmiita TypeScriptiä yhdellä napsautuksella. Tavoitteena on poistaa 80 % manuaalisesta, toistuvasta työstä, saaden tiedostosi sellaiseen tilaan, jossa kehittäjä voi astua sisään ja tehdä hienovaraisempaa työtä tarkkojen, merkityksellisten tyyppien soveltamiseksi.
Kun codemod on suoritettu, on hyvä idea tarkistaa tarkasti, mitä on muuttunut. Nopeaa visuaalista tarkistusta varten ennen kuin sitoudut mihinkään, voit käyttää ilmaista työkalua vertaamaan ennen ja jälkeen -tekstiä. Tämä auttaa sinua ymmärtämään, mitä kaavoja työkalu soveltaa.
Suositut automatisoidut muunnostyökalut
Useat työkalut voivat auttaa tässä alkuvaiheen muunnoksessa. Jokaisella on omat vahvuutensa, joten oikean valitseminen riippuu usein erityisestä pinostasi ja tavoitteistasi.
| Työkalun nimi | Päätoiminto | Paras käyttö | Keskeinen ominaisuus |
|---|---|---|---|
| ts-migrate | Kattava codemod-työkalupakki | Suuret, monimutkaiset koodipohjat, erityisesti React-projektit | Kokoelma kohdennettuja liitännäisiä eri siirtotehtäville |
| ts-morph | Koodin manipulointikirjasto | Mukautettujen, monimutkaisten siirtoskriptien rakentaminen | Syvällinen hallinta Abstraktista syntaksipuusta (AST) tarkkaa refaktorointia varten |
| TypeWiz | Kerää ajonaikaista tyyppitietoa | Projektit, joilla on hyvä testikattavuus | Ehdottaa tyyppejä sen perusteella, miten koodi käyttäytyy ajonaikana |
| js-to-ts-converter | Yksinkertainen online-muunnin | Nopeat muunnokset yksittäisistä tiedostoista tai pienistä koodinpätkistä | Verkkopohjainen käyttöliittymä helppoa kopiointi- ja liittämismuunnosta varten |
Vaikka työkalu kuten ts-migrate on loistava suurissa projekteissa, jotain kuten js-to-ts-converter voi olla hyödyllistä pienen apufunktion tai komponentin nopeassa muuntamisessa, jonka löysit verkosta.
Tieto automatisoinnin rajoista
Automaattiset muuntimet ovat uskomattoman voimakkaita, mutta ne eivät ole taikuutta. Ne ovat syntaktisten muutosten mestareita - asioita, jotka seuraavat selkeää, ennakoitavaa kaavaa. Mitä ne eivät voi tehdä, on ymmärtää liiketoimintalogiikkaa tai todellista tarkoitusta koodisi takana. Siinä kohtaa sinä, kehittäjä, olet korvaamaton.
Tässä on käytännön erittely siitä, mitä voit odottaa työkalun käsittelevän verrattuna siihen, mikä jää sinun vastuullesi.
Mitä automatisointi käsittelee hyvin ✅
- Tiedostojen nimeäminen uudelleen
.jsmuotoon.ts. any-tyypin lisääminen kaikkialle, jotta koodi kootaan.- Reactin
PropTypesmuuntaminen perus TypeScript -rajapintoihin. - Yksinkertaiset syntaksimuutokset ja pohjakoodimuutokset.
Mikä tarvitsee edelleen inhimillistä kosketusta 🧑💻
- Monimutkaisten, liiketoimintakohtaisten tyyppien määrittäminen (esim.
UserProfile,ShoppingCart,Invoice). - Ajatuksellisesti korvata jokainen
anytarkalla, tiukalla tyypillä. - Monimutkaisen ehdollisen logiikan tai kinkkisten reunaehtojen refaktorointi.
- Manuaalisesti lisätä tyyppejä kolmannen osapuolen kirjastoille, joilla ei ole virallisia
@types-paketteja.
Kokemukset yrityksiltä kuten Pinterest, joka siirsi yli 3,7 miljoonaa koodiriviä, ovat täydellinen esimerkki tästä yhdistetystä lähestymistavasta. He suorittivat automatisoidun codemodin alkuvaiheen raskasta työtä varten ja seurasivat sitten mukautetuilla skripteillä ja manuaalisilla korjauksilla käsitelläkseen kaikki vivahteet, joita työkalut eivät voineet ymmärtää.
Lopulta asiantuntemuksesi on viimeinen ainesosa, joka muuttaa syntaktisesti oikean koodipohjan todella tyyppiturvalliseksi, kestäväksi ja ylläpidettäväksi.
4. Refaktorointi luottavaisin mielin: 'Any' -tyypistä upeaksi
Automaattinen javascript to typescript converter vie projektisi lähtöviivalle - se hoitaa tylsät tiedostojen nimeämiset ja syntaksimuutokset, jättäen sinulle koodipohjan, joka teknisesti kootaan. Mutta tässä vaiheessa alkaa oikea työ ja todellinen arvo.
Huomaat, että tuoreesti muunnetut tiedostosi ovat täynnä any -tyyppiä, joka on TypeScriptin tapa sanoa: "Ei mitään hajua, mitä tämä on." Siirtyminen any -tyypistä upeaksi on manuaalinen prosessi, joka muuttaa projektin pelkästä "muunnetusta" todella kestäväksi, itseasiakirjoittavaksi ja ylläpidettäväksi.
Tämä refaktorointivaihe on vähemmän raakaa voimaa ja enemmän etsivätyötä. Tavoitteesi on metsästää jokainen any ja korvata se tarkalla tyypillä, joka todella kuvaa datan muotoa ja käyttäytymistä. Tämä ei ole vain akateeminen harjoitus; näin avaat TypeScriptin ydinhyödyt - löydät virheitä suoraan editorissasi, saat tehokasta automaattistäyttöä ja teet koodistasi dramaattisesti helpommin ymmärrettävää muille (ja tulevalle itsellesi).
On ihmisen kosketus, jota automaatio ei yksinkertaisesti voi jäljitellä.

Siistien Rajapintojen ja Tyyppialiasien Luominen
Ensimmäinen tehtäväsi on löytää ne monimutkaiset objektit, jotka leijuvat koodipohjassasi, ja antaa niille nimi ja muoto. Etsi funktioiden parametreja tai API-vastausdatan, johon muunnin on liittänyt any. Nämä ovat erinomaisia ehdokkaita muuttumaan rajapinnaksi tai tyyppialiasiksi.
Objektin muodon määrittämisessä rajapinta on paras ystäväsi. Esimerkiksi se user objekti, joka oli aina implisiittinen JavaScriptissäsi, voidaan nyt määrittää eksplisiittisesti.
Ennen: Epäselvä JavaScript-Objekti
function displayUser(user) { // Mitä on 'user'? Kuka tietää.
console.log(Welcome, ${user.firstName});
}
Jälkeen: Itse-dokumentoiva TypeScript-Rajapinta
interface UserProfile {
id: number;
firstName: string;
lastName: string;
email: string;
isAdmin?: boolean; // Valinnainen ominaisuus
}
function displayUser(user: UserProfile) {
console.log(Welcome, ${user.firstName});
}
Juuri näin, arvailu on poissa. Editorisi tietää tarkalleen, mitä ominaisuuksia user objektissa on, mikä tarkoittaa, että ei enää kirjoitusvirheitä ja äärimmäisen hyödyllistä automaattista täydennystä.
Joustavammille tai dynaamisemmille tietorakenteille tyyppialias on usein parempi vaihtoehto. Ne ovat loistavia luomaan unioneita, leikkauksia tai vain antamaan kuvaavampi nimi perus tyypille.
- Union Tyyppit:
type Status = 'pending' | 'approved' | 'rejected'; - Monimutkaiset Tyyppit:
type UserWithPosts = UserProfile & { posts: Post[] };
Funktioiden Tyypitys ja Kolmannen Osapuolen Koodi
Kun ydintietorakenteesi on määritelty, seuraava looginen askel on tyypittää funktiosi oikein. Tämä tarkoittaa tyypin määrittämistä sekä funktioon hyväksyttäville parametreille että sen palauttamalle arvolle, luoden vahvan "sopimuksen", jota TypeScript-kääntäjä voi valvoa.
Ota yksinkertainen apufunktio. Ilman tyyppejä toivot vain parasta.
Ennen: Huonosti Määritelty Funktio
function calculateTotal(items) {
return items.reduce((acc, item) => acc + item.price, 0);
}
Tämä koodi vain olettaa items olevan taulukko objekteista ja että jokaisella objektilla on price ominaisuus. TypeScript pakottaa sinut olemaan eksplisiittinen näiden oletusten suhteen.
Jälkeen: Tiukasti Tyypitetty Funktio
interface CartItem {
id: string;
name: string;
price: number;
}
function calculateTotal(items: CartItem[]): number {
return items.reduce((acc, item) => acc + item.price, 0);
}
Nyt se on kristallinkirkasta: tämä funktio ottaa vastaan taulukon CartItem objekteista ja on taattu palauttamaan number. Ei epäselvyyksiä.
Toinen yleinen este on kolmannen osapuolen kirjastoihin liittyminen. Hyvä uutinen on, että monet suositut paketit tarjoavat yhteisön ylläpitämiä tyyppimääritelmiä DefinitelyTyped -projektin kautta. Voit yleensä asentaa ne yksinkertaisella komennolla:npm install --save-dev @types/package-name
Nämä @types paketit asentamalla TypeScript saa syvällistä tietoa kirjaston API:sta, mikä parantaa kehityskokemustasi samalla automaattisella täydennyksellä ja tyypintarkistuksella, jonka saat omasta koodistasi.
Tämä strateginen lähestymistapa refaktorointiin tuo etuja, jotka ulottuvat paljon pidemmälle kuin vain kääntäjän tyydyttäminen. Hyvin tyypitetty koodi tarjoaa perustan, jonka päälle modernit kehitystyökalut voivat rakentaa, parantaen merkittävästi tuottavuutta.
Synergia TypeScriptin ja modernien kehitystyökalujen välillä on kiistaton. AI-koodausassistentit, kuten GitHub Copilot, Tabnine ja Cursor ovat kaikki merkittävästi tehokkaampia tyypitetyissä kielissä. Vuodesta 2025 alkaen suuret kielimallit (LLM) kuten GPT-5 ja erilaiset AI IDE -assistentit on suunniteltu käsittelemään tyypitettyjä koodipohjia tehokkaammin, mikä tekee tästä siirtymisestä älykkään valinnan työnkulkujesi tulevaisuuden turvaamiseksi. Voit löytää lisää näkemyksiä siitä, kuinka TypeScript parantaa modernia kehitystä abbacustechnologies.com.
Modernien Kehitysmallien Omaksuminen
Viimeiseksi, tämä refaktorointiprosessi on täydellinen tilaisuus modernisoida koodisi. Käyttämällä ominaisuuksia, kuten objektin purkamista tyypin annotaatioiden kanssa, voit tehdä funktioistasi tiiviimpiä ja luettavampia.
Ennen: Perinteinen Ominaisuuden Käyttö
function getAdminEmail(user: UserProfile): string | null {
if (user.isAdmin) {
return user.email;
}
return null;
}
Jälkeen: Purkaminen Tyypeillä
function getAdminEmail({ isAdmin, email }: UserProfile): string | null {
return isAdmin ? email : null;
}
Se on pieni muutos, mutta se tekee funktion riippuvuudet selkeämmiksi ja koodista siistimpää.
Korvaamalla järjestelmällisesti any, tyypittämällä funktiosi, integroimalla yhteisön tyyppejä ja omaksumalla moderneja malleja, muunnat koodipohjasi hauraasta JavaScript-projektista kestäväksi, kehittäjäystävälliseksi TypeScript-vahvaksi.<\/p>