Ett dokument d\u00f6k upp idag som pekar p\u00e5 att Deno kommer att sluta anv\u00e4nda TypeScript i sin interna kod, med h\u00e4nvisning till flera problem med den nuvarande milj\u00f6n. N\u00e4mnda fr\u00e5gor r\u00f6r bland annat TypeScript kompileringstider, strukturering och kodorganisation. Fram\u00f6ver kommer Deno att anv\u00e4nda ren JavaScript f\u00f6r sin interna kod.<\/p>\n
De ogynnsamma situationerna som Deno-teamet f\u00f6r n\u00e4rvarande upplever n\u00e4r de anv\u00e4nder TypeScript<\/a> f\u00f6r sin interna kod \u00e4r:<\/p>\n TypeScript-kompileringstid n\u00e4r filbyte tar flera minuter, vilket g\u00f6r kontinuerlig kompilering till en oerh\u00f6rt l\u00e5ngsam process<\/p>\n<\/li>\n Typescript-strukturen som de anv\u00e4nder i k\u00e4llfilerna som skapar den faktiska k\u00f6rbara Deno-filen och de anv\u00e4ndarv\u00e4nda API:erna skapar prestandaproblem vid k\u00f6rning<\/p>\n<\/li>\n TypeScript visar sig inte vara till hj\u00e4lp f\u00f6r att organisera Deno-kod. Tv\u00e4rtom, Deno-teamet upplever motsatt effekt. En av de fr\u00e5gor som n\u00e4mns \u00e4r att de slutade med dubbla oberoende kroppsklasser p\u00e5 tv\u00e5 platser https:\/\/github.com\/denoland\/deno\/issues\/4748<\/a><\/p>\n<\/li>\n Den interna koden och runtime TypeScript-deklarationerna m\u00e5ste h\u00e5llas synkroniserade manuellt eftersom TypeScript-kompilatorn inte \u00e4r till hj\u00e4lp f\u00f6r att generera d.ts-filerna<\/p>\n<\/li>\n De uppr\u00e4tth\u00e5ller tv\u00e5 TS-kompilatorv\u00e4rdar: en f\u00f6r den interna Deno-koden och en annan f\u00f6r extern anv\u00e4ndarkod \u00e4ven om b\u00e5da har ett liknande m\u00e5l<\/p>\n<\/li>\n<\/ul>\n Deno -teamet str\u00e4var<\/a> efter att ta bort all TS-typkontroll och buntning f\u00f6r intern Deno-kod. De ser fram emot att flytta all runtime-kod till en enda JavaScript<\/a> -fil. Men de kommer fortfarande att anv\u00e4nda en kompletterande d.ts-fil f\u00f6r att beh\u00e5lla typdefinitionerna och dokumentationen.<\/p>\n Det \u00e4r v\u00e4rt att n\u00e4mna att Deno kommer att sluta anv\u00e4nda TypeScript endast f\u00f6r den interna Deno-koden: Deno-anv\u00e4ndarkoden kommer fortfarande att finnas i TypeScript och \u00e4r d\u00e4rf\u00f6r typkontrollerad.<\/p>\n \u00c4ven om TypeScript ibland ses som en f\u00f6rb\u00e4ttrad version av JavaScript, visar det h\u00e4r fallet att det faktiskt inte \u00e4r det. Det har brister som alla andra spr\u00e5k. En av de viktigaste \u00e4r dess l\u00e5ngsamma kompileringstid. \u00c4ven om sm\u00e5 projekt kanske inte ser en enorm \u00f6kning i kompileringstid n\u00e4r man byter fr\u00e5n rent JavaScript till TypeScript, kommer det att m\u00e4rkas i stora projekt som en komplex React-<\/a> app. Med tanke p\u00e5 den stora k\u00f6rtiden \u00e4r det inte f\u00f6rv\u00e5nande att Deno kommer att sluta anv\u00e4nda TypeScript.<\/p>\n S\u00e4kerheten f\u00f6r typkontroll under utveckling har sin kostnad vid kompileringstillf\u00e4llet. Det \u00e4r inte utan anledning som TypeScript-projektet har ett omfattande dokument om hur man hanterar och f\u00f6rb\u00e4ttrar kompileringstiden<\/a>. Ett av de mest intressanta tillv\u00e4gag\u00e5ngss\u00e4tten \u00e4r att anv\u00e4nda Project References<\/a>, som g\u00f6r det m\u00f6jligt f\u00f6r utvecklare att bryta is\u00e4r ett stort TypeScript-kodstycke i mindre bitar.<\/p>\n Den fullst\u00e4ndiga diskussionen om beslutet att ta bort TypeScript fr\u00e5n den interna Deno-koden och anv\u00e4nda JavaScript ist\u00e4llet finns i det h\u00e4r dokumentet<\/a>, d\u00e4r Ryan Dahl och medarbetare diskuterar problemet, dess l\u00f6sning och hur det kommer att implementeras.<\/p>\n\n
Ta bort TypeScript i intern Deno-kod<\/h2>\n
L\u00e4s mer om varf\u00f6r Deno kommer att sluta anv\u00e4nda TypeScript<\/h2>\n