Fable: Nagareyama ne surveille pas plusieurs projets fsproj (et plusieurs répertoires sources F#)

Salut @tomcl ! Oui, vous pouvez signaler les problèmes de Fable 3 ici et je vous remercie de le faire

Hmm, j'ai testé Fable 3 dans plusieurs projets contenant des références de projet et tous les fichiers sources (y compris les sous-répertoires) sont surveillés. Cependant, je pense que la dernière version avait un bogue que je venais de corriger où si la première compilation contenait des erreurs F#, les modifications ne déclenchaient pas de recompilation de surveillance. C'est ton cas ? Sinon, cela se produit-il toujours (l'observateur ne réagit à aucun changement) ? As-tu testé avec d'autres projets ? Y a-t-il quelque chose de particulier dans votre configuration ? Serait-il possible de créer un dépôt pour reproduire le problème ?

Merci! Ok, donc mon repo est très complexe, j'ai pensé essayer d'abord le repo fable-elmish-electron-material-ui de cmeeren. Mon code est vaguement basé sur cela.

C'est une application electron-webpack. Sur celui-ci (fsproj unique pour le rendu et le principal), la surveillance fonctionne parfaitement, tout comme la surveillance de fable -> regroupement de dev electron-webpack. Je pense. Excepté:

  ERROR in ./src/Renderer/App.fs.js
  Module build failed (from ./node_modules/babel-loader/lib/index.js):
  SyntaxError: C:\github\fable-elmish-demo\src\Renderer\App.fs.js: Unexpected token, expected "," (202:4)

La sortie .fs.js ne semble pas être appréciée par electron-webpack

Il s'agit certainement d'une erreur différente de celle ci-dessus. Cependant, j'aimerais d'abord passer à une simple démonstration de travail avant de revenir à mon projet. Pour info - mon projet - contrairement à cette simple démo - se compile et s'exécute complètement

repo est https://github.com/tomcl/fable-elmish-demo/tree/dev-fable3 (notez la branche dev-fable3 dans le lien).

Re votre autre possible pour le bug de la montre d'origine : le code n'avait aucune erreur. d'après mes tests précédents, l'observateur n'a jamais rien recompilé. Je le soupçonne d'être quelque chose de stupide, sauf qu'il y a beaucoup de similitudes entre les systèmes et les outils entre la version fable-elmish-demo (qui se montre bien) et la version de mon référentiel (qui ne fonctionne pas).

Mon dépôt "ne pas regarder" est https://github.com/tomcl/ISSIE à nouveau la branche dev-fable3. Mais je ne garantis pas que ce sera très facile à construire, les trucs npm doivent être triés (ça marche, mais le fichier de construction utilise npm alors que je pense qu'il peut avoir besoin de fil pour faire l'installation initiale). Je réglerai cela si je ne peux pas reproduire le bogue sur quelque chose de plus simple, alors vous voudrez peut-être ne pas l'essayer encore.

La sortie de compilation Fable d'App.fs :

export const Theme_example = (() => {
    let color, color_1, styles_1, arg10, styles_2, props, props_1;
    const props_2 = ofArray([["palette.type", "dark"], (color = blueGrey, ["palette.primary", color]), (color_1 = purple, ["palette.secondary", color_1]), (styles_1 = ofArray([mkStyle("fontWeight", "bold"), (arg10 = singleton(mkStyle("backgroundColor", "#7FFFD4")), (mkStyle("\u0026$disabled", createObj(arg10))))]), ["overrides.MuiButtonBase.root", createObj(styles_1)]), (styles_2 = ofArray([mkStyle("borderWidth", 10), mkStyle("borderColor", "#000000"), mkStyle("borderStyle", "solid")]), ["overrides.MuiAvatar.img", createObj(styles_2)]), (props = singleton(mkAttr("size", "small")), ["props.MuiButton", createObj(props)]), (props_1 = singleton(mkAttr("fullScreen", true)), ["props.MuiDialog", createObj(props_1)])]);
    const merge = [];
    let theme;
    theme = (function setProperty(target, key, value) {
    const sepIdx = key.indexOf('.')
    if (sepIdx === -1) {
    target[key] = value
    } else {
    const topKey = key.substring(0, sepIdx)
    const nestedKey = key.substring(sepIdx + 1)
    if (target[topKey] === undefined) {
    target[topKey] = {}
    }
    setProperty(target[topKey], nestedKey, value)
    }
    }
    const target = {}
    for (let kv of props_2) {
    setProperty(target, kv[0], kv[1])
    }
    return target
    );
    return StyleImports_createMuiTheme_argsArray(theme, ...merge);
})();

Clairement pas comme il se doit, venant de :

module Theme =


  // Not used, but shows how to use style and prop overrides. The returned theme
  // can for example be used as the `theme` prop of `Mui.muiThemeProvider`.
  let example = Styles.createMuiTheme([
    theme.palette.type'.dark
    theme.palette.primary Colors.blueGrey
    theme.palette.secondary Colors.purple

    // Globally override component styles
    theme.overrides.muiButtonBase.root [
      style.fontWeight.bold
      style.inner "&$disabled" [
        style.backgroundColor.aquaMarine
      ]
    ]
    theme.overrides.muiAvatar.img [
      style.borderWidth 10
      style.borderColor.black
      style.borderStyle.solid
    ]

    // Globally override component props
    theme.props.muiButton [
      button.size.small
    ]
    theme.props.muiDialog [
      dialog.fullScreen true
    ]

  ])

Je ne suis pas vraiment préoccupé par ce bogue : il n'apparaît dans aucun de mes codes, je ne sais pas s'il mérite son propre problème.

OK, j'ai une version propre pour mon dépôt principal, montrant le bogue "pas de surveillance". En dehors de cela, il compile bien et démarre - il semble qu'il y ait un bogue supplémentaire (peut-être pas fable3, mais différent de la version précédente de fable2). Je réglerai cela si possible après les travaux de compilation de la montre, car la recompilation de la montre/HMR rendra l'enquête beaucoup plus rapide. Si le bogue supplémentaire existe, je le signalerai comme un problème distinct.

Dépôt de build propre affichant le bogue « pas de surveillance » :

https://github.com/tomcl/fable-elmish-demo/tree/dev-fable3

La note doit être dev-fable3 branche

build (Windows) ou dotnet fake build installera et construira le code. Il entrera en mode montre/hmr, mais cela ne fonctionnera pas car la montre fable3 ne regarde pas.

npm run compile affichera le bogue de la surveillance, la compilation du processus principal (OK) puis la compilation/surveillance du processus de rendu - qui compile correctement mais ne regarde pas, par exemple, changer src/renderer/renderer.fs

npm run watchmain montre qu'il regarde correctement le projet principal (structure beaucoup plus simple).

PS - Je suis très impatient d'utiliser Fable3. cela accélérera le cycle de développement, et comme l'application utilise beaucoup de cartes, cela accélérera peut-être l'application. J'espère que Nagareyama pourra être assez stable d'ici la mi-janvier de l'année prochaine car j'aurai alors 60 étudiants de 3e année à l'université travaillant tous sur ce code...

Le code incorrect de votre commentaire

Pour autant que je sache, votre processus de construction (à la fois dans https://github.com/tomcl/fable-elmish-demo/tree/dev-fable3 et dans https://github.com/tomcl/issie/tree/ dev-fable3) n'invoque tout simplement pas Fable avant d'exécuter Webpack. Avec Fable 3, nous n'avons plus de chargeur dédié pour Webpack, le compilateur Fable doit donc être exécuté en premier.

J'invoque Fable 3 comme suit dans mon référentiel EDITÉ : https://github.com/tomcl/issie/tree/dev-fable3
"dev": "dotnet fable src/main && dotnet fable watch src/renderer --run electron-webpack dev" . Je m'attends à ce que cela compile le processus principal (c'est le cas), puis compile (oui, c'est le cas) et surveille (non, je pense que c'est un bogue) le processus de rendu.

La version par défaut appelle ce script.

Je me suis trompé dans mon commentaire ci-dessus en suggérant npm run compile qui ne regardera jamais car il invoque la fable sans regarder.

Mais en tout cas je testais aussi avec seulement dotnet fable watch src/renderer . C'est le moyen le plus simple de voir le bogue _no watch_.

OK - J'ai exécuté femto sur ce référentiel cmeeren et mis à jour toutes les dépendances, y compris material-ui. Cela ne change pas le bogue qui montre un javascript syntaxiquement incorrect sortant de F# syntaxiquement correct. Il y a peut-être de mauvaises définitions d'émission quelque part, je suppose, mais ce n'est pas évident pour moi.

Mais personnellement, je n'ai aucune inquiétude à propos de ce problème, ce n'est pas mon code, et ma base de code est entièrement compilée en javascript correct. (Je pense).

Hm, je n'arrive pas à trouver la sous-chaîne dotnet fable dans le référentiel (tomcl/fable-elmish-demo). Mais dotnet fable watch src/Renderer/ --run electron-webpack dev fonctionne également sur ma machine, jusqu'à ce qu'il rencontre la syntaxe invalide dans le fichier JS généré.

Désolé, j'ai posté le mauvais lien ! je voulais dire
Mon dépôt https://github.com/tomcl/issie/tree/dev-fable3

Le repo cmeeren fonctionne bien. Alors ignorez ce dépôt. Je ne l'ai mis en évidence que parce qu'il semblait y avoir un bogue distinct que quelqu'un pourrait vouloir connaître.

J'ai maintenant trié mon dépôt (passé toute la nuit dernière à faire cela) pour construire facilement et simplement, montre le bogue de surveillance dans une structure avec 3 projets liés et plusieurs répertoires sources.

fable watch src/renderer

Fabel3 dit "regarder 'src'" mais ne regarde pas les sous-répertoires src/renderer etc.

OK - donc je pense maintenant comprendre le problème de la montre. C'est juste une fonctionnalité, pas un bogue, comme suit.

Watch fonctionne sur tous les fichiers .fs du projet ou sur les projets dépendants, à condition que le _répertoire actuel_ soit le même que le répertoire .fsproj .

Ainsi pour un projet src/renderer/myproj.fsproj :

dotnet fable watch src/renderer compilera mais ne regardera pas

dotnet fable watch . --cwd src/renderer compilera mais ne regardera pas.

cd src/renderer

suivie par

fable watch . compilera et regardera.

C'est un peu contre-intuitif, mais facile à contourner dans des cas simples.

Dans un cas complexe comme mon dépôt, où le script dev doit exécuter et surveiller le projet principal, puis exécuter et surveiller le projet de rendu, puis exécuter electron-webpack qui lui-même s'exécute et surveille, c'est plus difficile. Cela aiderait s'il n'y avait aucune exigence pour que le répertoire actuel soit le même que le fichier fsproj.

Cet ensemble de scripts fonctionne pour mon application électronique. et le temps de compilation et de chargement typique est 1/10 de ce qu'il était avant : la solution précédente recompilerait tous les fichiers.

    "dev": "cd src/main && dotnet fable watch . --run npm run devr",
    "devr": "cd src/renderer && dotnet fable watch . --run npm run webpack",
    "webpack": "electron-webpack dev",

Merci beaucoup pour votre enquête et pour l'exemple de dépôt @tomcl @inosik ! Je suis très heureux d'apprendre que la compilation typique est 10 fois plus rapide qu'avant :tada:

Il devrait être possible de regarder les sous-répertoires même si vous n'êtes pas dans le même répertoire que le projet. J'exécute généralement dotnet fable partir de la racine du référentiel et l'observateur fonctionne correctement. Si vous êtes intéressé, voici comment l'observateur est démarré :

• Démarrez un FileSystemWatcher avec le filtre .fs(x|proj) qui inclut des sous-répertoires
• Une fois la compilation Fable terminée, sélectionnez le répertoire de base commun pour tous les fichiers source, définissez-le comme chemin de l'observateur et activez les événements de déclenchement.
• Lorsqu'un événement est déclenché, vérifiez que le fichier appartient au projet

https://github.com/fable-compiler/Fable/blob/41ccfc253c890292b2514402089c594eabf485cf/src/Fable.Cli/Main.fs#L206 -L241

J'ai testé la branche dev-fable3 vous avez gentiment préparée dans le repo issie. Cela fonctionnait pour moi mais j'ai dû ajuster la commande. Peut-être que Fable watcher fonctionnait mais qu'il n'a pas déclenché de compilation Webpack car --watch manquait lors de l'appel de Webpack. La commande suivante a fonctionné pour moi à partir de la racine du référentiel :

dotnet fable watch src/Renderer --run webpack --config webpack.additions.renderer.js --watch

Chaque fois que je changeais Renderer.fs, un nouveau bundle était créé. Cependant, le bundle échouait car il manquait à webpack.config.js Sass et les chargeurs de fichiers, ainsi que la cible electron-renderer .

@tomcl Pourriez-vous s'il vous plaît essayer si cette commande ☝️ fonctionne pour vous ? BTW, Issie a l'air génial ! Je l'ai téléchargé et j'ai joué un peu avec. Mais je n'ai qu'un projet vide donc ce n'est pas très excitant à partager. Vous avez un projet plus compliqué ou des captures d'écran, des gifs à tweeter à ce sujet ?

Merci! Le truc, c'est que electron-webpack est un module qui fait tout ça (webpack + setup + watch). Ainsi, web-config.js est généré automatiquement et n'est normalement pas utilisé, et les fichiers "ajouts" sont minimes.

Je trouvais juste en train d'exécuter dotnet fable watch tout seul qu'il ne se recompilait pas lors du visionnage dans les cas que j'ai indiqués - mais peut-être que je faisais quelque chose de mal? Ou, est-ce que fable3 s'attend à s'interfacer avec webpack d'une manière ou d'une autre, plutôt que de simplement communiquer via les fichiers surveillés (il surveille le .fs, génère js et electron-webpack ou webpack surveille le .js) ?

J'ai maintenant une version entièrement fonctionnelle avec les trois dernières lignes de mon dernier message. C'est peut-être étrange, mais il surveille tout et compile automatiquement et HMR.

Oui, je suis très content d'Issie. Il a une interface utilisateur assez merveilleuse pour son objectif. Son principal problème est draw2d qui est une bibliothèque géniale mais v complexe et l'InteractiveManhattanRouter qui permet un routage automatique rapide très intuitif des connexions a un bogue js qui conduit à des boucles infinies avec débordement de pile parfois lors du déplacement de composants et donc du routage automatique des connexions. De plus, draw2d fait beaucoup de calculs coûteux sur les cadres de délimitation - assez inutiles dans notre cas d'utilisation - ce qui le rend très lent. Cela peut prendre 15s pour charger une grande feuille de conception et c'est tout Draw2d qui prend beaucoup de temps pour ajouter des figures à sa toile.

Il semble donc être une bonne idée de faire un équivalent réduit de fable/elmish pour ce dont Issie a besoin. C'est prévu au printemps pour être intégré à Issie l'été prochain si tout se passe bien.

Nous avons des projets Issie assez importants - le plus important est un processeur complet avec environ 10 feuilles de conception. J'attends de le publier jusqu'à ce que la construction et les fonctionnalités soient un peu plus triées. Nous aurons une utilisation intensive par les étudiants avec des circuits complexes le prochain semestre, ce terme est une utilisation plus légère pour éliminer les bugs, donc cela devrait être bon pour la publicité à ce moment-là.

En transférant vers Fable 3, les deux problèmes pour moi (à part regarder l'étrangeté) étaient :

(1) SimpleJson.stringify - J'avais une ancienne version du package sans sérialisation. Le fichier Readme documente bien cela doit être utilisé avec la fable 3. Aucun problème pour le changer en Json.serialize<'T> une fois que j'ai mis à jour les packages. Peut-être que Fable3 pourrait avoir une vérification de version de package minimum ou quelque chose du genre ? Mais je ne comprends pas bien l'emballage nuget/paket.

(2) L'application a utilisé List.distinct sur une liste d'objets JS. Cela a éclaté sous Fable3 comme vous pouvez l'imaginer. J'ai utilisé distinctBy et un identifiant de chaîne pour réparer cela.

(3) J'ai mesuré les performances de la carte par rapport à l'ancienne Fable. Mon cas de test était des cartes de taille 3, 20, 100. J'ai regardé la recherche de carte et la mise à jour de carte, comme les deux opérations. Pour tout cela, la vitesse était très similaire. Fable 3 arrive environ 10% mieux pour les plus grandes cartes.

Voici un circuit (simple) qui montre qu'il fait quelque chose et vous permet d'exécuter le simulateur d'onde - ce qui est plutôt bon.

Merci beaucoup @tomcl ! J'ai tweeté à propos d'Issie et les gens adorent ça ! https://twitter.com/FableCompiler/status/1329451503107641348?s=19

À propos de SimpleJson, il s'est appuyé sur certains détails d'implémentation qui ont changé dans Fable 3, mais Zaid a corrigé et dans la version stable de Fable, nous fournirons en effet un moyen de distinguer la version du compilateur pour prendre en charge à la fois Fable 2 et 3 si nécessaire. @inosik a également résolu le problème avec List.distinct !

Je ne sais pas s'il s'agit du même problème, mais je ne semble pas pouvoir le faire regarder mon dossier appelant dotnet fable watch soit dans le même répertoire que le projet ou avec le projet spécifié. Pas de chance avec dotnet fable watch . non plus. Exécution de RC8.

Edit : Pas de chance avec RC10 non plus.

Ce qui a fonctionné pour moi avec une configuration électronique compliquée qui nécessite de surveiller les processus main et renderer :

    "compile": "dotnet fable src/main && dotnet fable src/Renderer",
    "dev": "cd src/Main && dotnet fable watch . --run npm run devrenderer",
    "devmain": "cd src/Main && dotnet fable watch . --run npm run webpackdev",
    "devrenderer": "cd src/Renderer && dotnet fable watch . --run npm run webpackdev",

Dans tous les cas, la montre est utilisée sur . . --run est utilisé pour exécuter webpack tout en continuant à regarder. Pour regarder à la fois le principal et le moteur --run rendu,

Pouvez-vous s'il vous plaît vérifier si dotnet watch -p src/Renderer test fonctionne pour vous ? Juste pour vérifier si la surveillance réelle des fichiers fonctionne. La commande exécutera dotnet test si un fichier dans un projet référencé change.

oui, dotnet watch -p src\Renderer semble fonctionner correctement à la fois à l'intérieur et à travers les projets.

Peut-être que le #2301 pourrait vous aider ? Sinon je suis à court d'idées. Nous devrons soit déboguer cela, soit recommencer à zéro et ajouter des éléments jusqu'à ce qu'il commence à casser.

Je crois que j'ai compris!

Que ce soit System.IO.Path.GetFullPath ou System.IO.Directory.GetCurrentDirectory() , Windows ne renverra à un appelant d'API que le nom du dossier tel qu'il est donné dans le paramètre, qu'il s'agisse ou non de la bonne majuscule.

Donc System.IO.Path.GetFullPath @"c:\windows" renverra toujours "c:\windows" même s'il s'agit techniquement de "C:\Windows". La même chose s'applique si votre répertoire de travail dans un shell ou un outil de construction ou autre n'est pas correctement mis en majuscule.

Par conséquent, lorsque Fable.Cli.Main.FsWatcher.Observe compare le chemin du fichier modifié à la liste des fichiers à vérifier, si le répertoire de travail ou le chemin dans la ligne de commande est mal mis en majuscule, il ne correspondra pas.

La solution simple consiste à appeler ToLower() (ou ToUpper() ) sur fullPath et sur chaque élément dans filesToWatch premier. Cela produira des faux positifs sur les systèmes de fichiers sensibles à la casse.

Pour être absolument certain que ce ne sera pas le cas, la bonne solution pourrait être d'utiliser l'une des solutions à cette question SO - bien que, honnêtement, il soit probablement plus sûr de simplement continuer et recompiler tout fichier qui porte le même nom avec une capitalisation différente de ce qu'elle serait pour risquer des faux négatifs causés par le fait que les solutions SO n'ont pas été testées sur certains systèmes de fichiers.

Si vous voulez pointer et croiser ts, vous pouvez vérifier tout le chemin pour les doublons et émettre un avertissement sévère _sans_ compiler les éléments mal placés. En suivant le principe de la dactylographie forte, vous pourriez affirmer qu'appliquer la discipline des cas de cette manière serait mieux que de contourner l'absence d'une telle discipline qui pourrait briser d'autres outils !

Mais je suis plus pragmatique, dans ce cas, je pense que contourner les problèmes de cas - et également émettre un avertissement, serait la solution optimale. FABLE résout un problème technique complexe, et tout pour réduire les problèmes de débutant est bon,

C'est clairement un cas où je suis coupable d'une grave désorganisation en ne prêtant pas plus d'attention à la casse des noms de fichiers. C'est cependant pénible, et la suggestion de reinux y remédierait.

Oh mon Dieu, merci beaucoup @reinux ! C'est tout à fait logique. En fait, je suis un idiot car nous avons eu un problème similaire lors de la déduplication des chemins dans le répertoire de sortie et je ne me suis pas rendu compte que cela pouvait être la même chose avec l'observateur. Je vais appliquer votre solution, les faux positifs ne devraient pas être un gros problème ici et il vaut mieux prévenir que guérir comme vous le dites. Merci encore!

Cool, merci @alfonsogarciacaro !

Je viens de lire un peu plus sur la sensibilité à la casse dans les systèmes de fichiers parce que cela me tient littéralement éveillé la nuit, et c'est en fait un peu horrible - et même pas seulement sous Windows.

Par exemple, si vous montez un système de fichiers insensible à la casse sur *nix, qui à sa racine est sensible à la casse, certaines parties du chemin seront sensibles à la casse et d'autres non. La notion de "système de fichiers sensible à la casse" est également un peu ambiguë, NTFS lui-même étant apparemment insensible à la casse alors que les API Win32 ne le sont pas - jusqu'à ce que vous activiez la sensibilité à la casse en utilisant fsutil.exe sur une base par répertoire .

Soooo... J'ai probablement fait la même erreur 3269874 fois aussi, et je ne le saurai même pas jusqu'à ce qu'il me manque un fichier ou quelque chose.

Le haut est en bas, le noir est blanc et la terre est plate

... et @reinux mérite plus d'une émoticône hourra !

Le nettoyage du boîtier a résolu mon bug de construction étrange #2285 #2293. Mais voyez là pour les commentaires, car je pense qu'il y a un problème avec les bibliothèques dans les répertoires .fable .