TypeScript

La version 5 de Svelte vient de sortir : 5.0.0.

Il y a un an, j'avais lu le billet Introducing runes. Depuis, j'ai suivi ce sujet de loin.

J'aimerais tester et apprendre à utiliser la fonctionnalité rune.
#JeMeDemande dans quel projet 🤔. Est-ce que je préfère refactorer vers rune le projet sklein-pkm-engine ou gibbon-replay 🤔. Je pense que ces deux projets utilisent trop peu de "reactive state".
Je souhaite prochainement débuter le projet que j'ai présenté dans 2023-10-28_2008. Je pense que ça serait une bonne occasion pour créer mon premier projet 100% TypeScript avec Svelte 5 avec Rune.

J'aime utiliser la syntax de query de Postgres.js basé sur ES2015 tagged template string, par exemple :

const result = await sql`SELECT * FROM name = ${name}`;

Je cherche la même chose pour SQLite et #JaiDécouvert https://github.com/blakeembrey/sql-template-tag.

J'ai redécouvert squid et postguard.
Je pense que postguard est surtout utile avec TypeScript.

#JaiDécouvert et un peu étudié Temporal (workflow management).

D'après ce que j'ai compris, Temporal a été initialement développé par les auteurs (Maxim Fateev et Samar Abbas) de Cadence.

Je me souviens d'avoir étudié Cadence vers 2019. J'ai l'impression que ce projet est encore très actif. #JeMeDemande quelles sont les réelles différences entre Temporal et Cadence 🤔.

• Cadence Use cases
• Temporal features

Une première réponse à ma question :

• Temporal supporte les langages Go, Java, PHP, Python, TypeScript, dotNET alors que Cadence est limitée aux langages Go et Java.
• Cadence propose une UI nommée cadence-web qui semble plus minimaliste que temporalio/ui.

D'après ce que j'ai lu, Temporal est totalement open-source, sous licence MIT. L'entreprise Temporal propose une version hébergée (managée) nommée Temporal Cloud.

#JaiDécouvert un exemple de projet d'Order Management System codé en Go et basé sur Temporal : https://github.com/temporalio/reference-app-orders-go.
Je n'ai pas étudié le code source, mais c'est un sujet qui m'intéresse, étant donné que j'ai travaillé par le passé sur le développement d'un Order Management System 😉.

Dans la branche gibbon-replay-js du projet Idée d'un outil de session recoding web minimaliste basé sur rrweb, j'ai essayé sans succès d'extraire du code dans un package Javascript.

Pour le moment l'import suivant ne fonctionne pas :

import gibbonReplayJs from 'gibbon-replay-js';

Quand je lance pnpm run build, j'ai l'erreur suivante :

$ pnpm run build
...
x Build failed in 336ms
error during build:
src/routes/(record)/+layout.svelte (2:11): "default" is not exported by "packages/gibbon-replay-js/dist/index.js", imported by "src/routes/(record)/+layout.svelte".
file: /home/stephane/git/github.com/stephane-klein/gibbon-replay-poc/src/routes/(record)/+layout.svelte:2:11

1: <script>
2:     import gibbonReplayJs from 'gibbon-replay-js';

Et quand je lance pnpm run dev, j'ai l'erreur suivante :

$ pnpm run dev

...

11:21:21 [vite] Error when evaluating SSR module /packages/gibbon-replay-js/dist/index.js:
|- ReferenceError: exports is not defined
    at eval (/home/stephane/git/github.com/stephane-klein/gibbon-replay-poc/packages/gibbon-replay-js/dist/index.js:5:23)
    at instantiateModule (file:///home/stephane/git/github.com/stephane-klein/gibbon-replay-poc/node_modules/.pnpm/vite@5.4.3/node_modules/vite/dist/node/chunks/dep-BaOMuo4I.js:52904:11)

11:21:21 [vite] Error when evaluating SSR module /src/routes/(record)/+layout.svelte:
|- ReferenceError: exports is not defined
    at eval (/home/stephane/git/github.com/stephane-klein/gibbon-replay-poc/packages/gibbon-replay-js/dist/index.js:5:23)
    at instantiateModule (file:///home/stephane/git/github.com/stephane-klein/gibbon-replay-poc/node_modules/.pnpm/vite@5.4.3/node_modules/vite/dist/node/chunks/dep-BaOMuo4I.js:52904:11)

Suite à cette frustration, j'ai envie de créer un projet, sans doute nommé javascript-package-playground dans lequel je souhaite étudier les sujets suivants :

• mise en place d'une librairie /packages/lib1/ qui contient une librairie javascript, qui peut être importé avec la méthode ECMAScript Modules ;
• mise en place d'une app NodeJS dans /services/app1_nodejs/ qui utilise lib1 ;
• mise en place d'une app SvelteKit dans /services/app2_sveltekit/ qui utilise lib1 dans un fichier coté server et dans une page web coté browser ;
• mise en place d'une librairie /packages/lib2 qui utilise lib1

Je souhaite décliner ces 2 libs et 2 apps sous plusieurs déclinaisons d'implémentation :

• avec le build basé sur tsc
• avec le build basé sur esbuild
• avec le build basé sur Babel (Javascript)
• et sans build

Et le tout encore dans deux déclinaisons : Javascript et TypeScript.

Je ne souhaite pas supporter CommonJS qui est sur le déclin, remplacé par ECMAScript Modules.

Dans ce playground, je souhaite aussi me perfectionner dans l'usage de pnpm link et pnpm workspace.

#JeMeDemande si ces connaissances sont totalement maitrisées et évidentes chez mes amis développeurs Javascript 🤔 et s'ils les considèrent comme "basiques".

Je ressamble ici quelques notes au sujet de l'évolution de usage de TypeScript dans le temps.

Ces informations proviennent de State of JavaScript .

Année 2016

https://2016.stateofjs.com/2016/flavors/

Année 2020

JavaScript flavors usage :

https://2020.stateofjs.com/en-US/technologies/javascript-flavors/

Année 2022

https://2022.stateofjs.com/en-US/usage/#js_ts_balance

Année 2023

https://2023.stateofjs.com/en-US/usage/#js_ts_balance

#JaiLu le thread Hacker News Turbo 8 is dropping TypeScript.

Quelques extraits :

I highly recommend reading the PR discussion for this.

https://github.com/hotwired/turbo/pull/971

Some summary:

• forced through without any discussion
• many maintainers raising questions, but no answers
• random changes attached to the PR (formatters, etc)

Wherever you land on types, I think we can agree that this is not an ideal way to make a change to a larger open source project. This has all the hallmarks of an executive decision made on a whim, and forced through at the last minute. Lead maintainers certainly have the right to make big changes on a whim, but giving people some notice before breaking other projects and having good communication is true leadership.

---

After using TypeScript I could never go back. The amount of times it's saved me or got me up to speed quickly is countless. It does come with a cost and god the error messages are just awful sometimes but I'd die before I ever work in a js only project again.

---

I wonder if type annotations (JSDoc) on plain JS could be the way to go. Lint, but don’t compile. This should work seamlessly with NPM modules etc.

Voici un extrait de l'article Turbo 8 is dropping TypeScript de David Heinemeier Hansson (DHH de Basecamp) :

This isn't a plea to convert anyone of anything, though. As I discussed in Programming types and mindsets, very few programmers are typically interested in having their opinion on typing changed. Most programmers find themselves drawn strongly to typing or not quite early in their career, and then spend the rest of it rationalizing The Correct Choice to themselves and others.

Je trouve ce point de vue intéressant.

Voir aussi : TypeScript

#JaiLu

Rich Harris explains this clearly. JSDoc for writing a lib. TypeScript for writing an app. (from)

Ce conseil entre en opposition avec ce que j'ai écrit en octobre 2023 :

Si je dois coder et publier une librairie sur npm alors, je choisis TypeScript.
Quand je dis librairie, je parle de librairie qui contient des classes, des fonctions ou des composants importés par d'autres projets.

Pourquoi est-ce que je choisis d'utiliser TypeScript pour les librairies ?

• Je permets aux développeurs qui utilisent TypeScript dans leur projet, de pouvoir bénéficier de la documentation, l'autocomplétion, la détection des erreurs… de la librairie que j'aurais mise à disposition ;
• Je n'ai pas vérifié, mais je pense que le typage de TypeScript permet à des outils d'auto générer une grande partie de la documentation d'une librairie.

Ce conseil entre aussi en opposition avec ce second élément que j'ai écrit en octobre 2023 :

Si je dois coder une application web, alors pour le moment, je choisis JavaScript.
Le code implémenté dans une application web, n'est généralement pas utilisé par des utilisateurs "externes". Par conséquent, je ne trouve pas très important de mettre à disposition une documentation aux autres développeurs. Je pense qu'à petite taille, l'effort ne vaut pas la peine. Ma réponse est peut-être différente si 10, 20… développeurs contribuent à la même base code 🤔.

• Généralement, le code d'une application web est plutôt simple, beaucoup de CRUD et peu de librairie complexe.
• Pour le moment, je pense que l'effort d'ajouter le boilerplate code de typage TypeScript (importer les types, d'ajouter le typage dans le code) ne sera pas compensé par les fonctionnalités de détection d'erreurs , d'autocomplétions et de refactoring que permet TypeScript.

Je pense qu'il serait bon que je revoie ma doctrine d'artisan développeur sur ce sujet.

#OnMaPartagé Alexandre : 5 Inconvenient Truths about TypeScript (TypeScript)

Cette après midi, j'hésite à migrer le projet sveltekit-tendaro-webshell-skeleton de Javascript vers TypeScript.

Je me demande si :

• cela en vaut la peine ;
• étant donné que je n'ai jamais fait pour de vrai un projet en TypeScript, est-ce que je ne risque pas de tomber dans un Yak! 🤔.

Actuellement ma doctrine concernant TypeScript est la suivante.

Si je dois coder et publier une librairie sur npm alors, je choisis TypeScript.
Quand je dis librairie, je parle de librairie qui contient des classes, des fonctions ou des composants importés par d'autres projets.

Pourquoi est-ce que je choisis d'utiliser TypeScript pour les librairies ?

• Je permets aux développeurs qui utilisent TypeScript dans leur projet, de pouvoir bénéficier de la documentation, l'autocomplétion, la détection des erreurs… de la librairie que j'aurais mise à disposition ;
• Je n'ai pas vérifié, mais je pense que le typage de TypeScript permet à des outils d'auto générer une grande partie de la documentation d'une librairie.

Si je dois coder une application web, alors pour le moment, je choisis JavaScript.
Le code implémenté dans une application web, n'est généralement pas utilisé par des utilisateurs "externes". Par conséquent, je ne trouve pas très important de mettre à disposition une documentation aux autres développeurs. Je pense qu'à petite taille, l'effort ne vaut pas la peine. Ma réponse est peut-être différente si 10, 20… développeurs contribuent à la même base code 🤔.

• Généralement, le code d'une application web est plutôt simple, beaucoup de CRUD et peu de librairie complexe.
• Pour le moment, je pense que l'effort d'ajouter le boilerplate code de typage TypeScript (importer les types, d'ajouter le typage dans le code) ne sera pas compensé par les fonctionnalités de détection d'erreurs , d'autocomplétions et de refactoring que permet TypeScript.

Mais je me dis que je me trompe peut-être, peut-être que si j'essaie, je vais me rendre compte que j'aime bien cela et que cela me fera gagner du temps ou alors améliorera mon confort, mon plaisir de développement 🤔.

Tâches à faire si je souhaite migrer à TypeScript :

• [ ] Implémenter une déclinaison de sveltekit-ssr-skeleton en TypeScript
• [ ] Modifier mon environnement Neovim pour activer les fonctionnalités suivantes :
  • [ ] Support de l'autocomplétion TypeScript
  • [ ] Support de la détection des erreurs TypeScript
  • [ ] Support des fonctions de refactoring TypeScript
  • [ ] Affichage en "live" de la documentation des composants, fonctions…

Ressources à lire avant pour avancer sur ce sujet :

• [ ] Big projects are ditching TypeScript… wtf? - The Code Report
• [ ] Turbo 8 is dropping TypeScript