Un document a fait surface aujourd’hui indiquant que Deno cessera d’utiliser TypeScript dans son code interne, citant plusieurs probl\u00e8mes avec l’environnement actuel. Les probl\u00e8mes mentionn\u00e9s concernent les temps de compilation TypeScript, la structuration et l’organisation du code, entre autres. \u00c0 l’avenir, Deno utilisera du JavaScript pur pour son code interne.<\/p>\n
Les situations d\u00e9favorables que l’\u00e9quipe Deno rencontre actuellement lors de l’utilisation de TypeScript<\/a> pour son code interne sont\u00a0:<\/p>\n Le temps de compilation de TypeScript lorsque la modification des fichiers prend plusieurs minutes, ce qui rend la compilation continue un processus extr\u00eamement lent<\/p>\n<\/li>\n La structure Typescript qu’ils utilisent dans les fichiers source qui cr\u00e9ent l’ex\u00e9cutable Deno r\u00e9el et les API orient\u00e9es utilisateur cr\u00e9ent des probl\u00e8mes de performances d’ex\u00e9cution<\/p>\n<\/li>\n TypeScript ne s’av\u00e8re pas utile pour organiser le code Deno. Au contraire, l’\u00e9quipe Deno subit l’effet inverse. L’un des probl\u00e8mes mentionn\u00e9s est qu’ils se sont retrouv\u00e9s avec des classes Body ind\u00e9pendantes en double \u00e0 deux endroits https:\/\/github.com\/denoland\/deno\/issues\/4748<\/a><\/p>\n<\/li>\n Le code interne et les d\u00e9clarations TypeScript d’ex\u00e9cution doivent \u00eatre synchronis\u00e9s manuellement car le compilateur TypeScript n’est pas utile pour g\u00e9n\u00e9rer les fichiers d.ts<\/p>\n<\/li>\n Ils maintiennent deux h\u00f4tes de compilateur TS\u00a0: un pour le code interne Deno et un autre pour le code utilisateur externe, m\u00eame si les deux ont un objectif similaire.<\/p>\n<\/li>\n<\/ul>\n L’ \u00e9quipe Deno<\/a> vise \u00e0 supprimer toutes les v\u00e9rifications et regroupements de type TS au moment de la construction pour le code Deno interne. Ils sont impatients de d\u00e9placer tout le code d’ex\u00e9cution dans un seul fichier JavaScript<\/a>. Cependant, ils utiliseront toujours un fichier d.ts compagnon pour conserver les d\u00e9finitions de type et la documentation.<\/p>\n Il convient de mentionner que Deno cessera d’utiliser TypeScript uniquement pour le code Deno interne\u00a0: le code utilisateur Deno sera toujours dans TypeScript et donc v\u00e9rifi\u00e9.<\/p>\n Alors que TypeScript est parfois consid\u00e9r\u00e9 comme une version am\u00e9lior\u00e9e de JavaScript, ce cas montre qu’en fait, ce n’est pas le cas. Il a des d\u00e9fauts comme n’importe quelle autre langue. L’un des plus importants est son temps de compilation lent. Bien que les petits projets puissent ne pas voir un \u00e9norme pic de temps de compilation lors du passage de JavaScript pur \u00e0 TypeScript, cela sera perceptible dans les grands projets comme une application React<\/a> complexe. Compte tenu de la grande taille de son environnement d’ex\u00e9cution, il n’est pas surprenant que Deno cesse d’utiliser TypeScript.<\/p>\n La s\u00e9curit\u00e9 de la v\u00e9rification des types pendant le d\u00e9veloppement a un co\u00fbt au moment de la compilation. Ce n’est pas sans raison que le projet TypeScript dispose d’un document complet sur la fa\u00e7on d’aborder et d’ am\u00e9liorer le temps de compilation<\/a>. L’une des approches les plus int\u00e9ressantes consiste \u00e0 utiliser Project References<\/a>, qui permet aux d\u00e9veloppeurs de d\u00e9composer un gros morceau de code TypeScript en morceaux plus petits.<\/p>\n La discussion compl\u00e8te sur la d\u00e9cision de supprimer TypeScript du code interne de Deno et d’utiliser JavaScript \u00e0 la place se trouve dans ce document<\/a>, o\u00f9 Ryan Dahl et ses collaborateurs discutent du probl\u00e8me, de sa solution et de la mani\u00e8re dont il va \u00eatre impl\u00e9ment\u00e9.<\/p>\n\n
Suppression de TypeScript dans le code Deno interne<\/h2>\n
En savoir plus sur les raisons pour lesquelles Deno cessera d’utiliser TypeScript<\/h2>\n