Fable: [Aide recherchée/Conception] Améliorer l'intégration de TypeScript

L'autre jour, je travaillais à faire en sorte que ts2fable fonctionne mieux pour traduire les types. Mais j'ai arrêté après avoir commencé à rencontrer des problèmes avec le besoin d'unions étiquetées par type. https://github.com/fsharp/fslang-suggestions/issues/538
De plus, je n'ai pas trouvé de bon moyen de représenter le polymorphisme de ligne Pick avec le polymorphisme de colonne F#. Ils ne correspondent pas tout à fait pour une traduction 1: 1 des types.

Peut-être pourrions-nous faire le contraire, convertir tout le TypeScript AST en F # AST. [insérez le rire d'un informaticien maléfique et fou]

Merci beaucoup pour ce numéro détaillé @matthid. Comme nous avons parlé de certains types, il est vrai que je suis un peu sceptique quant à l'intégration de Typescript car, comme le dit @Luiz-Monad, les systèmes de typage des deux langues diffèrent un peu. Mais j'aimerais avoir tort et voir comment nous pouvons tirer parti des déclarations .d.ts.

Je peux voir que vous avez fait vos devoirs et répertorié les anciens problèmes autour du sujet, donc je n'ai pas besoin de répéter l'information... ou de la chercher moi-même parce que je l'ai déjà oublié :) Mais je vais quand même essayez d'ajouter quelques commentaires au fur et à mesure que je me souviens des choses. Pour l'instant deux notes rapides :

• Il y a déjà un travail en cours par @ncave pour ramener les annotations dans le Babel AST #1615. Babel peut maintenant analyser Typescript, mais je ne me souviens pas si cela fonctionne dans l'autre sens (les annotations dans Babel AST utilisées pour émettre Typescript).
• À propos de l'importation de fichiers F # dans Typescript, j'ai remarqué que le problème est que Typescript ne vous permet pas de déclarer un module non-js avec un chemin relatif. Il y a une note à ce sujet maintenant dans les docs.

Merci!

Mais j'ai arrêté après avoir commencé à rencontrer des problèmes avec le besoin d'unions étiquetées par type.
De plus, je n'ai pas trouvé de bon moyen de représenter le polymorphisme de ligne Pick avec le polymorphisme de colonne F #

Comme nous avons parlé de certains types, il est vrai que je suis un peu sceptique quant à l'intégration de Typescript car, comme le dit @Luiz-Monad, les systèmes de typage des deux langues diffèrent un peu.

Oui, je pense que c'est en effet un problème, mais ma pensée actuelle est que ce n'est vraiment un problème que pour "2". pas pour "1". (ou connaissez-vous des exemples où cela pose problème pour "1." ?). En général, on a l'impression que le système de type TypeScript est plus puissant que celui de F#. Il s'agit probablement d'un problème général dans l'écosystème, car TypeScript essaie simplement de "taper" le javascript existant. Donc, cela signifie essentiellement que nous avons des problèmes pour mapper le code existant sur notre système de type.

Pour résoudre ce problème pour "2". nous ne sommes pas perdus non plus :

• À long terme : Ouvrir des suggestions comme vous l'avez fait, mais nous devons également faire pression sur les discussions pour qu'elles restent utiles pour la fable (comme vous pouvez le voir sur https://github.com/fsharp/fslang-suggestions/issues/538)
• À court terme : nous pouvons mapper des types inconnus sur "obj" ou un type de base commun de l'union.
• À moyen terme : nous sommes un compilateur afin que nous puissions faire de la génération de code et émettre des accesseurs similaires à la façon dont nous les écrivions manuellement à la main. Mais nous devons penser à la compatibilité pour cela.

Il y a déjà un travail en cours par @ncave pour ramener les annotations dans le Babel AST #1615. Babel peut maintenant analyser Typescript, mais je ne me souviens pas si cela fonctionne dans l'autre sens (les annotations dans Babel AST utilisées pour émettre Typescript).

J'ai fait quelques recherches avec google mais je n'arrive pas à comprendre quel est l'avantage de cela. Si babel ne peut pas écrire de fichiers .d.ts à partir de cela, à quoi cela sert-il ? Peut-être que vous ou @ncave pouvez expliquer ?

À propos de l'importation de fichiers F # dans Typescript, j'ai remarqué que le problème est que Typescript ne vous permet pas de déclarer un module non-js avec un chemin relatif. Il y a une note à ce sujet maintenant dans les docs.

Oui, je pense que nous avons besoin d'un peu de bricolage pour que cette importation fonctionne parfaitement, mais dans le pire des cas, nous pouvons également générer un fichier .ts qui importe la déclaration et l'importation appropriée .fs , puis nous pouvons dire aux gens d'importer .ts au lieu de .fs ?

mais je ne me souviens pas si cela fonctionne dans l'autre sens (les annotations dans Babel AST utilisées pour émettre Typescript)

Si je me souviens bien, Babel ne prend en charge que la compilation de TypeScript en JavaScript. Il ne génère pas de TypeScript.

Au début de Fable Conf, au moins, il a été expliqué qu'ils voulaient prendre en charge la transpilation TypeScropt -> JavaScript et faire un "meilleur travail" que le compilateur TypeScript en raison de tout l'écosystème Babel, de la configuration et de l'optimisation.

Lors des premières tentatives de génération de fichiers .d.ts, j'ai utilisé babel-dts-generator qui était capable d'extraire les annotations de Babel AST pour créer les déclarations. Mais il semble que le plugin ne soit pas pris en charge maintenant :/ Une autre option serait de sortir les annotations sous forme de commentaires JSDoc, car Typescript peut également les utiliser pour fournir intellisense .

Si je ne me trompe pas, le but de @ncave était de faire en sorte que Babel produise les annotations de type sous forme de commentaires, puis de faire une autre passe pour les supprimer et enfin de voir si le résultat était compatible avec l'un de ces sous-ensembles Typescripts ciblant WebAssembly comme AssemblyScript . Oui, de la magie noire comme d'habitude :wink: Mais si dans les deux cas le but est d'inclure des annotations de type dans la sortie ce sera l'occasion de faire d'une pierre deux coups.

Une autre option serait de sortir les annotations sous forme de commentaires JSDoc,

J'ai vu cette suggestion, mais je doute que ce soit plus facile que d'écrire des définitions TypeScript via l'API. D'un autre côté, si nous les obtenons "gratuitement" de Babel, ce serait une autre histoire et probablement l'approche la plus simple.

La question est de savoir comment cela s'adapte aux bibliothèques ? Je suppose que nous suggérons d'inclure des commentaires dans le bundle ?

@alfonsogarciacaro

• Nous pouvons peut-être fusionner #1615 tel quel, c'est derrière une option du compilateur donc c'est non intrusif. Il peut être agréable de laisser les gens jouer avec sur le REPL, si l'option est exposée dans l'interface utilisateur.
• # 1615 n'a pas beaucoup changé au cours de la dernière année (juste rebasé), mais il vous amène déjà assez loin dans la sortie des annotations de type (et d'autres peuvent être ajoutées facilement).
• La première étape après cela serait de s'assurer que le fable-library se compile en quelque chose que le compilateur TypeScript peut accepter.
• L'une des premières annotations de type à corriger concerne les paramètres de la fonction, qui doivent être non curry pour correspondre à la non curry sur le site d'appel.

Remarque latérale :

• Je prévoyais d'utiliser ce PR pour générer des types à compiler avec AssemblyScript. Malheureusement, ce projet n'a pas progressé autant que je l'espérais au cours de la dernière année. Il a obtenu le comptage de références GC, mais manque toujours de prise en charge de certaines fonctionnalités de base telles que les fermetures et les itérateurs (peut-être parce que l'assemblage Web lui-même est lent à ajouter les fonctionnalités requises pour prendre en charge cela hors de la boîte).

J'espère que cela changera à l'avenir, mais en attendant, cibler TypeScript devrait être beaucoup plus facile.

La première étape après cela serait de s'assurer que la fable-library se compile en quelque chose que le compilateur TypeScript peut accepter.

J'espère que cela changera à l'avenir, mais en attendant, cibler TypeScript devrait être beaucoup plus facile.

Je ne sais pas ce que cela signifie. Cela signifie-t-il que la voie à suivre consiste à transférer la sortie au format JSDoc dans le compilateur TypeScript, qui écrira lui-même les fichiers .d.ts ? Ou voulez-vous dire écrire des fichiers .d.ts à partir de la fable elle-même ? Pouvez-vous s'il vous plaît clarifier @ncave ?

Ou en d'autres termes : je suis prêt à investir du temps dans ce problème, mais après toutes ces discussions, je ne sais toujours pas quel est notre meilleur pari pour le moment ?

@mattid L'ajout d' annotations de type dans Babel AST génère directement des types dans la sortie Babel. C'est juste une question d'exhaustivité (sortir les annotations de type correctes pour tous les cas extrêmes). Par example:

let rec factorial n =
    if n = 0 then 1
    else n * factorial (n-1)

let iterate action (array: 'T[]) =
    for i = 0 to array.Length - 1 do
        action array.[i]

let rec sum xs =
    match xs with
    | []    -> 0
    | y::ys -> y + sum ys

se compile en (avec les annotations de type activées) :

export function factorial(n: number): number {
  if (n === 0) {
    return 1;
  } else {
    return n * factorial(n - 1) | 0;
  }
}
export function iterate<T>(action: (arg0: T) => void, array: Array<T>): void {
  for (let i = 0; i <= array.length - 1; i++) {
    action(array[i]);
  }
}
export function sum(xs: any): number {
  if (xs.tail != null) {
    const ys = xs.tail;
    const y = xs.head | 0;
    return y + sum(ys) | 0;
  } else {
    return 0;
  }
}

Comme vous pouvez le voir, ce n'est pas parfait et il y a du travail à faire (un certain nombre de types sont simplement remplacés par any pour l'instant), mais IMO, vous pouvez aller assez loin avec ça.

@ncave Et je suppose que TypeScript peut consommer JavaScript annoté ootb? Ou devons-nous traiter cela plus avant ?

@matthid Ce qui précède est un TypeScript valide produit par Babel, il suffit de renommer .js en .ts .
Mais comme je l'ai dit, le PR a besoin d'amour pour ajouter les types appropriés, cela n'a pas vraiment beaucoup changé depuis que @alfonsogarciacaro a ajouté pour la première fois des annotations de type il y a très très longtemps dans Fable 1.

Je vais regarder de plus près le week-end, merci pour la précision

Je vais bientôt créer une branche next pour la prochaine version majeure afin de fusionner #1839. Nous pourrions également l'utiliser pour fusionner #1615 et l'expérimenter :)

Je voulais juste intervenir et dire que j'ai été très intéressé par l'introduction de Fable dans mon travail. Nous avons une base de code TypeScript 200k + LOC, donc avoir un certain niveau d'intégration TypeScript dans Fable serait _énorme_.

Je souhaite principalement que Fable émette des liaisons TypeScript afin qu'il soit plus facile d'incorporer une bibliothèque Fable dans notre base de code TypeScript existante.

J'ai bricolé avec certains des résultats des travaux récents de ncave, en essayant de trouver un moyen de créer des types TypeScrypt afin que les unions F # soient typées avec précision et puissent être discriminées avec une instruction switch sans casser la structure d'objet existante. Est-ce le bon endroit pour poster des idées ?

@chrisvanderpennen Bien sûr, pourquoi pas, si c'est lié. Ou vous pour ouvrir un sujet de discussion séparé, si vous le souhaitez.

Déplacé vers #2096

@chrisvanderpennen Merci pour l'explication détaillée, il est probablement préférable de convertir cela en son propre problème [demande de fonctionnalité], car cela va probablement un peu au-delà de la portée initiale de l'ajout de types.

Bien sûr, je vais en créer un et modifier ce qui précède pour qu'il pointe dessus afin de ne pas encombrer cette discussion.

Jusqu'à présent, je pense que l'idée est d'éviter le javascript/dactylographié, mais que se passe-t-il si vous pouvez l'adopter ?

J'ai récemment travaillé avec [Bolero] qui est juste de l'assemblage Web, et la façon dont il fait l'interopérabilité javascript est en faisant des invocations de fonction

https://github.com/AngelMunoz/Mandadin/blob/master/src/Mandadin.Client/Views/Notes.fs#L79

// next version of blazor will actually change
// to import the whole module (store the ref) then invoke the function
// instead of the actual Global Namespacing
Cmd.OfJS.either js "Namespace.MyFn" [||] Success Error

et côté javascript, il me reste à écrire du code à la main

https://github.com/AngelMunoz/Mandadin/tree/master/src/Mandadin.Client/wwwroot/js

et inclure mes bibliothèques js, si cela devient assez gros, je pense que vous devrez de toute façon regrouper ces fichiers et dépendances

Fable utilise déjà Webpack et ce ne sont que des fichiers javascript typescript/javascript, au final, du moins c'est ce que je pense.
Les typages/dépendances ne sont qu'à une "installation npm".

// interop/my-file.ts
// to be included in the final fable bundle
import { libraryFn } from 'the-library-i-wont-write-bindings-to'
// hide the library interop/specifical JS work
function parseThingsAndWorkWithLibraries() { /* ... */ }
function imDoingStuff(someParam)  {
    // code 
    let someParam = someParam['something'] = myfn();
    const parsed = parseThingsAndWorkWithLibraries(someParam)
    return return  { parsed }
}

// export only the F# interop bits
export async function myInteropFn(paramA: string, paramB: number): { my: string, fsharpType: boolean }} {
    try {
        const [unshapedResult, anotherResult] = await Promise.all([
            libraryFn(paramA, paramB), imDoingStuff(paramA)
        ]);
        return { my: unshapedResult.my_value, fsharpType: anotherResult.secondValue };
    } catch(err) {
        return Promise.reject(err.message);
    }
}

et pourrait être consommé d'une manière similaire à celle-ci

// in the fable code somewhere 
[<ImportMember("my-file")>]
let myInteropFn(params: string * number ): {| my: string; fsharpType: boolean |} = jsNative

Cmd.OfJS.either js myInteropFn ("value", 10) Success Error

Mon processus de réflexion ici était que si Fable pouvait implémenter une option d'interopérabilité dans un domaine similaire, la complexité de l'interopérabilité js serait à la frontière F#/JS, et non dans le manque de mains pour investir dans l'outillage/les liaisons

maintenant, ce serait le "pire cas", ce qui signifie que vous n'y auriez recours que si la bibliothèque est vraiment assez grande pour vous-même ou si la communauté ne fait aucun effort pour écrire des liaisons, la sécurité sera toujours du côté F #

Je pense que la plupart du temps, vous n'avez pas vraiment besoin de bibliothèques externes et les plus populaires sont peut-être déjà couvertes

de toute façon ... c'est juste une idée que j'ai eue en travaillant avec Bolero Je pense que Fable a une meilleure chance d'améliorer ce modèle d'interopérabilité que Blazor/Bolero puisque les packages vivent déjà dans npm, il y a trop peu de versions de bibliothèques prêtes pour le navigateur pour Blazor/ Bolero au travail, au final, j'ai l'impression qu'ils vont encore recourir au groupage d'une manière ou d'une autre

Merci beaucoup pour vos commentaires @AngelMunoz! Je ne suis pas sûr de comprendre, il existe déjà plusieurs façons d'interopérer avec le code JS de Fable de manière typée ou non, que recherchez-vous spécifiquement ? https://fable.io/docs/communicate/js-from-fable.html

mon commentaire concerne l'intégration de bibliothèques tierces, qui est compliquée à automatiser (ts2fable) et peut être sujette à des erreurs, également la seule autre alternative est de créer des liaisons pour des bibliothèques tierces et parfois il n'y a tout simplement pas assez de mains d'où la nécessité d'améliorer l'intégration de dactylographie , ou c'est ce que j'ai compris du fil de discussion.

le résumé serait le suivant
si Fable inclut un ensemble javascript/typescript créé par l'utilisateur dans la même application, vous devez utiliser le js des mécanismes habituels de fable sans avoir à écrire des liaisons pour chaque bibliothèque, les liaisons seraient pour votre code spécifique

c'est peut-être un autre problème et je ne saisis pas l'idée

@alfonsogarciacaro
suite d'hier c'est ce que je voulais dire
https://github.com/AngelMunoz/fable-plus-typescript-files-poc/blob/master/src/App.fs#L8
https://github.com/AngelMunoz/fable-plus-typescript-files-poc/blob/master/src/tsfiles/interop.ts#L18

cela ne traite pas le point 1

Émettre des liaisons TypeScript (nous les écrivons actuellement à la main)

mais cela fournit moins de friction pour le point 2 du problème

Consommer/Importer TypeScript (nous utilisons actuellement ts2fable pour cela)

cela apporte bien sûr son propre ensemble de problèmes, le premier auquel je peux penser est la sécurité, le système de type tapuscrit peut être vraiment bon mais a besoin de renforts de l'utilisateur contrairement à F # qui est plus sûr par défaut

À propos du point 1, @ncave y travaille, bien que le travail soit un peu suspendu jusqu'à ce que nous publiions une Fable 3 stable. Le point 2 concerne la consommation directe de fichiers dactylographiés de manière sécurisée avec des liaisons (ou avec des liaisons générées automatiquement sur la mouche). Je pense que c'est compliqué mais que cela pourrait être fait avec un fournisseur de type ou un outil de génération de code.

Dans tous les cas, comme indiqué ci-dessus, il est déjà possible de consommer des fichiers Typescript ou JS en utilisant des opérateurs dynamiques ou en écrivant des liaisons ad hoc (je le fais tout le temps). Pas besoin de mécanisme supplémentaire.

@alfonsogarciacaro : quand vous dites que le point 1 est en cours, cela signifie-t-il l'utilisation de "--typescript" dans la fable 3 ? C'est de ça que tu parles ?
si oui, il semble que ce drapeau crée un vrai code tapuscrit (pas seulement des déclarations)
mon but :créer une bibliothèque en Fable que j'aimerais utiliser dans une autre bibliothèque (cette seconde en tapuscrit). lors de l'utilisation du drapeau "--typescript", j'obtiens des erreurs

import { decimal } from "./.fable/fable-library.3.0.1/Decimal.js"; // error : ... has no exported member decimal ...

Je comprends que c'est un travail en cours, mais pourriez-vous ajouter un lien vers le travail ?
Où devrions-nous ajouter des problèmes concernant cette fonctionnalité spécifique ?
quelle est la bonne façon d'utiliser actuellement une bibliothèque Fable dans une autre bibliothèque dactylographiée ?

@CedricDumont oui, c'est vrai. Bien que je dois avouer que je n'ai pas travaillé sur cette fonctionnalité 😅 donc je ne sais pas vraiment quel est l'état actuel. @ncave peut probablement mieux répondre à cela. IIRC, les importations de fable-library posent des problèmes car nous n'emballons pas les fichiers fable-library compilés en dactylographié. Nous pouvons essayer de résoudre ce problème, mais je ne sais pas s'il y a d'autres problèmes en suspens. Si nous voulons donner une impulsion à cette fonctionnalité, nous devrions essayer de faire exécuter les tests lors de la compilation vers Typescript.

quelle est la bonne façon d'utiliser actuellement une bibliothèque Fable dans une autre bibliothèque de caractères dactylographiés ?

À l'heure actuelle, écrivez vous-même la déclaration .d.ts pour les méthodes Fable que vous consommez à partir de TS. J'ai trouvé la configuration suivante pour fonctionner:

App.fs
App.fs.js # generated
App.d.ts # manually written

Par exemple, si votre déclaration App.d.ts contient l'exportation suivante (correspondant à une exportation réelle dans App.fs.js) :

export function foo(x: number): {
    data: string[]
};

Vous pouvez le consommer à partir de Typescript comme ceci :

import { foo } from "./App"

const result = foo(5);

Notez que l'extension est omise lors de l'importation. Vous devez modifier votre webpack.config.js afin que Webpack recherche les fichiers avec l'extension .fs.js dans ce cas :

module.exports = {
    resolve: {
        extensions: ['.fs.js', '.mjs', '.js'], // Add other extensions you may want to use
    },
    ...
}

Notez que cela est également utile pour consommer du code Fable si vous utilisez uniquement Javascript avec l'instruction // @ts-check .

Voici l'état actuel du support TypeScript, basé sur ce commentaire :

En ce qui concerne les progrès, nous avons pu compiler fable-library en TypeScript strict dans Fable 2.
Dans Fable 3, nous avons eu un peu de régression à cause des nombreux changements, mais ça se rapproche à nouveau.
Après cela, le prochain grand objectif serait de compiler tous les tests en TypeScript strict, mais cela a une portée beaucoup plus grande.

Nous avons donc une petite bosse à franchir en premier, et une plus grosse après, mais j'espère qu'elle pourra être semi-utilisable après la première, si nous regroupons la version TS de fable-library avec le compilateur Fable. Les opinions et les contributions sont les bienvenues, les étapes de construction pour TS fable-library sont décrites dans le commentaire mentionné ci-dessus.

Fermeture car il n'y a pas de travail en cours pour le moment dans cette direction, veuillez rouvrir si quelqu'un veut contribuer à l'intégration de TS.