Discussion :

[Beginner.]

Salut,

J'ouvre ce fil pour éviter de trop dévier le sujet du fil : [webpack] Question sur les imports / require.

Je reproduit ma question ici :

S'il s'agit de modules pour node, il s'agit de modules pour le backend et en backend le tree shaking n'a pas de sens. Après il y a souvent un build pour le browser qui lui peut être en module ES6 et donc supporter le tree shaking. Lodash par exemple propose de nombreux livrables différents en fonction de ce que l'on veut faire.

Ah voilà un truc que je n'ai pas encore bien compris : avant node il y avait bien des librairies (je ne sais pas quel mot employé mais je veux dire librairie mais aussi n'importe quel code qui permet d'avoir par exemple un éditeur, un linter, un parser html...) alors on pouvait utiliser cette librairie dans un navigateur simplement en ajoutant une balise script dans notre page web mais aujourd’hui je constate que la plupart des librairies sont proposé sous forme de module/package Node à installer avec npm...

Alors comment je fais pour utiliser ces modules/packages comme on le faisait avant ? Je dois utiliser un bundler (j'ai déjà essayé Browserify) ? Il me semble (corrigez-moi si je me trompe) que tous ces modules/packages n'ont pas toujours une "version pour navigateur" comme c'est le cas de Lodash si je t'ai bien compris...

Si on prend l'exemple de ESLint, je crois avoir lu qu'ils avaient eu quelques soucis pour faire leur démo sur le navigateur, en tous cas j'ai plutôt l'impression qu'on doit l'utiliser avec Node... Mais j'ai du mal à imaginer la chose : on aurait coté client un éditeur de code et l'analyse du code se ferait coté serveur, c'est ça ? Du coup à chaque changement du code je dois envoyer ce dernier au serveur et récupérer sa réponse ?

J'aurais plutôt penser que le linter serait chargé coté client... Mais là on en revient au problème de départ l'usage des modules/packages dans le navigateur...

---> Du coup comment font les IDE ? Ils embarquent Node et un serveur ?

[Marco46]

Alors comment je fais pour utiliser ces modules/packages comme on le faisait avant ?

Ben tout pareil qu'avant tu vas chercher le fichier à importer en suivant le chemin.

Sauf que généralement tu ne vas pas déployer sur un serveur web ton source tel quel (je parle pour un projet frontend). D'où les bundlers.

Je dois utiliser un bundler (j'ai déjà essayé Browserify) ?

Un bundler va simplifier la construction du livrable qui sera déployé sur ton serveur web. C'est pas que tu dois l'utiliser, c'est juste que ça aide. Avant ça on faisait soit à la main (dans le pire des cas), soit on faisait des scripts (et pas en javascript, avant l'existence de node il était impossible d'exécuter du javascript ailleurs que dans un navigateur). Puis après on a eu node donc des outils ont vu le jour (grunt, gulp, ...), les bundlers c'est une évolution supplémentaire qui nécessite moins de code à écrire que grunt ou gulp.

Il me semble (corrigez-moi si je me trompe) que tous ces modules/packages n'ont pas toujours une "version pour navigateur" comme c'est le cas de Lodash si je t'ai bien compris...

Alors en fait lodash peut s'exécuter aussi bien back ou front out of the box parce qu'il ne fait pas appel aux API spécifiques au front ou au back. L'API spécifique frontend c'est l'API DOM (pour capter les événements déclenchés par l'utilisateur, manipuler le DOM, etc ...), l'api spécifique back c'est l'API de node.js (pour créer un serveur web, manipuler le filesystem, etc ...).

Donc si une lib packagée avec npm utilise une fonction de l'API DOM, il va de soit que ça va être chaud de l'utiliser côté back (tu vas capter le clic de quoi sur ton serveur ?), et inversement (c'est chaud de manipuler un fichier du filesystem depuis le browser).

npm est un gestionnaire de package JavaScript écrit en node, mais il est agnostique concernant le contenu, tu peux packager des libs exclusivement front, exclusivement back, ou utilisable dans les deux cas.

Si on prend l'exemple de ESLint, je crois avoir lu qu'ils avaient eu quelques soucis pour faire leur démo sur le navigateur, en tous cas j'ai plutôt l'impression qu'on doit l'utiliser avec Node...

Ben comme le but de ESLint c'est d'analyser des fichiers JavaScript ça m'étonne pas trop. Ca doit faire appel à plein de choses de l'API node qui ne sont pas dispo quand t'es dans un browser.

Mais j'ai du mal à imaginer la chose : on aurait coté client un éditeur de code et l'analyse du code se ferait coté serveur, c'est ça ? Du coup à chaque changement du code je dois envoyer ce dernier au serveur et récupérer sa réponse ?

Ya pas forcément un serveur quand tu exécutes un script node. Node.js c'est une plateforme, un peu comme la JRE de Java. T'as plein d'outils écrits avec node.js qui n'ont rien à faire du réseau et de http. Ben ESLint par exemple. En exemple encore pire t'as Electron qui sert à écrire des programmes client lourd comme Visual Studio Code, ATOM ou la version desktop de Slack.

---> Du coup comment font les IDE ? Ils embarquent Node et un serveur ?

Non, ils utilisent l'installation de Node présente sur le système.

[Beginner.]

Merci.

Alors en fait lodash peut s'exécuter aussi bien back ou front out of the box parce qu'il ne fait pas appel aux API spécifiques au front ou au back. L'API spécifique frontend c'est l'API DOM (pour capter les événements déclenchés par l'utilisateur, manipuler le DOM, etc ...), l'api spécifique back c'est l'API de node.js (pour créer un serveur web, manipuler le filesystem, etc ...).

Donc si une lib packagée avec npm utilise une fonction de l'API DOM, il va de soit que ça va être chaud de l'utiliser côté back (tu vas capter le clic de quoi sur ton serveur ?), et inversement (c'est chaud de manipuler un fichier du filesystem depuis le browser).

npm est un gestionnaire de package JavaScript écrit en node, mais il est agnostique concernant le contenu, tu peux packager des libs exclusivement front, exclusivement back, ou utilisable dans les deux cas.

Ok ça c'est clair.

Ben comme le but de ESLint c'est d'analyser des fichiers JavaScript ça m'étonne pas trop. Ca doit faire appel à plein de choses de l'API node qui ne sont pas dispo quand t'es dans un browser.

Oui tout à fait mais il pourrait aussi analyser le code sans avoir à lire des fichiers : le code serait par exemple passé sous la forme d'une string et les options seraient passées via un objet JS.

Ya pas forcément un serveur quand tu exécutes un script node. Node.js c'est une plateforme, un peu comme la JRE de Java. T'as plein d'outils écrits avec node.js qui n'ont rien à faire du réseau et de http. Ben ESLint par exemple. En exemple encore pire t'as Electron qui sert à écrire des programmes client lourd comme Visual Studio Code, ATOM ou la version desktop de Slack.

Ah oui c'est vrai je suppose qu'à force de répéter en gros que Node permet d’exécuter du JS coté serveur on finit par penser qu'un serveur est nécessaire... Alors qu'en fait c'est une application à part entière pouvant être exécuté sous Windows ou autres OS.

Mais je me demande comment les éditeurs comme par exemple ceux que tu cites à savoir Atom ou VSCode font pour utiliser les outils disponibles sous forme de module/package Node, est-ce qu'il lance en interne l'application node.exe comme on le fait manuellement avec la ligne de commande ? Si oui comment font-ils pour récupérer le résultat ? Avec la ligne de commande le résultat s'affiche dans le terminal mais on ne peut pas exploiter cela par programme, c'est juste visuel... Or à l'évidence ces éditeurs sont capables de récupérer automatiquement le résultat pour pouvoir l'exploiter par programme...

- Alors c'est vrai que j'ai remarqué que certains modules/packages proposent (en plus de l'exécution via la ligne de commande CLI) une api qui permet d'utiliser l'outils dans un code JS qu'on exécute avec node. Or justement je crois qu'avec Electron on peut exécuter ce type de code JS (car il embarque node ?) et comme il embarque aussi un navigateur (chrome), on peut je suppose récupérer les résultats, les exploiter et alors afficher les fruits de cette exploitation dans une page html. Par exemple pour fixer les idées on analyse le code avec ESlint à l'aide de l'api, on récupère le résultat sous la forme d'un objet ou d'un tableau d'objets et alors on affiche dans la page web des icônes d'erreurs ou d'avertissement à coté des lignes de code...

Ce serait une possibilité ?

[Beginner.]

Mais je me demande comment les éditeurs comme par exemple ceux que tu cites à savoir Atom ou VSCode font pour utiliser les outils disponibles sous forme de module/package Node, est-ce qu'il lance en interne l'application node.exe comme on le fait manuellement avec la ligne de commande ? Si oui comment font-ils pour récupérer le résultat ? Avec la ligne de commande le résultat s'affiche dans le terminal mais on ne peut pas exploiter cela par programme, c'est juste visuel... Or à l'évidence ces éditeurs sont capables de récupérer automatiquement le résultat pour pouvoir l'exploiter par programme...

Ah oui j'ai vu par exemple qu'avec ESLint il y a la possibilité de lui demander d'écrire les resultats de l'analyse dans un fichier alors peut-être que c'est comme ça que font les éditeurs, ils lisent ce fichier pour récupérer ces résultats ?

Ce serait une autre possibilité (en plus de celle dont je parle dans le message précédent c'est-à-dire celle qui utilise l'api fournit avec le module Node).

[Marco46]

Oui tout à fait mais il pourrait aussi analyser le code sans avoir à lire des fichiers : le code serait par exemple passé sous la forme d'une string et les options seraient passées via un objet JS.

Non mais déjà le fait de vouloir exécuter ESLint dans un browser ça n'a pas de sens. Je pense que le but était de fournir un analyseur online pour tester. Mais le but c'est d'analyser le code d'un repo, donc c'est forcément sur desktop. C'est ça l'usage dans 99,9999999999999999999% des cas. Le cas browser c'est un use case spécifique à la marge.

Alors qu'en fait c'est une application à part entière pouvant être exécuté sous Windows ou autres OS.

C'est une plateforme de développement comme une autre (Java, Python, etc ...). Vu la filiation c'est forcément orienté web mais ce n'est pas exclusif.

Mais je me demande comment les éditeurs comme par exemple ceux que tu cites à savoir Atom ou VSCode font pour utiliser les outils disponibles sous forme de module/package Node,

Ils ont un package.json qui décrit leurs dépendances, s'ils ont besoin d'ajouter lodash à leur projet par exemple ya un dev qui exécute npm install lodash, ça modifie le package.json (depuis la v5+ de npm), et dans leur code source (qui est écrit en JavaScript évidemment) ils importent la dépendance là où ils en ont besoin (const _ = require('lodash');). Ya pas de magie plus que ça tu t'attendais à quoi ?

est-ce qu'il lance en interne l'application node.exe comme on le fait manuellement avec la ligne de commande ?

Pour lancer une version de dev oui mais le livrable final est généré et il finit sous la forme d'un binaire exécutable, il y a donc une compilation par plateforme.

- Alors c'est vrai que j'ai remarqué que certains modules/packages proposent (en plus de l'exécution via la ligne de commande CLI) une api qui permet d'utiliser l'outils dans un code JS qu'on exécute avec node.

Ça dépend de l'outil et de son but. Le truc c'est que npm est un système de packaging, tu peux packager ce que tu veux avec. Certains s'en servent pour déployer des applis (souvent des dépendances de développement), et d'autres pour du code source. Comme je te le disais, npm est agnostique sur le contenu, tu pourrais très bien déployer des films de gladiateurs avec c'est pas un problème.

Or justement je crois qu'avec Electron on peut exécuter ce type de code JS (car il embarque node ?)

Non t'as pas compris que Electron, c'est du node et donc c'est du JavaScript.

et comme il embarque aussi un navigateur (chrome), on peut je suppose récupérer les résultats, les exploiter et alors afficher les fruits de cette exploitation dans une page html.

React est beaucoup utilisé pour gérer l'UI dans Electron.

Par exemple pour fixer les idées on analyse le code avec ESlint à l'aide de l'api, on récupère le résultat sous la forme d'un objet ou d'un tableau d'objets et alors on affiche dans la page web des icônes d'erreurs ou d'avertissement à coté des lignes de code...

Ce serait une possibilité ?

Je pense que plutôt que de te poser ces questions, tu ferais mieux de télécharger l'outil et de faire des tests, non ?

[Beginner.]

Merci.

J'avais commencé à écrire une réponse mais hélas il y a eu une coupure de courant...

Il y a encore des choses qui m'échappent... Il faut que je fasse la part des choses...

Non mais déjà le fait de vouloir exécuter ESLint dans un browser ça n'a pas de sens. Je pense que le but était de fournir un analyseur online pour tester. Mais le but c'est d'analyser le code d'un repo, donc c'est forcément sur desktop. C'est ça l'usage dans 99,9999999999999999999% des cas. Le cas browser c'est un use case spécifique à la marge.

Pour ce qui de l'usage d'un navigateur, si j'y pense c'est parce que les exemples que je connais s’exécutent dans un navigateur : il y a l'IDE cloud9 par exemple et j'utilise aussi jsbin qui utilise bien un linter...

Et pour ce qui est de VSCode ou Atom il me semble qu'il utilisent aussi un navigateur "embarqué"... Je crois qu'il y a aussi Bracket.

Mais si je comprends bien les plupart des applications n'utilisent pas de navigateurs.

Ils ont un package.json qui décrit leurs dépendances, s'ils ont besoin d'ajouter lodash à leur projet par exemple ya un dev qui exécute npm install lodash, ça modifie le package.json (depuis la v5+ de npm), et dans leur code source (qui est écrit en JavaScript évidemment) ils importent la dépendance là où ils en ont besoin (const _ = require('lodash'). Ya pas de magie plus que ça tu t'attendais à quoi ?

Ok donc ça rejoint ce que je disais puisque pour pouvoir utiliser les module/package Node de cette manière il faut bien que ces derniers proposent une api, non ?

Cette api permet d'utiliser le module/package Node dans notre code JS, c'est-à-dire que dans cette façon de faire on n'utilise pas la ligne de commande (sauf bien sûr pour exécuter notre code JS utilisant les api).

Pour lancer une version de dev oui mais le livrable final est généré et il finit sous la forme d'un binaire exécutable, il y a donc une compilation par plateforme.

Oui ben justement c'est un des points qui m'échappent : comment on fait en général pour développer une application deskop (utilisant des modules Node) qui soit exécutable sous Windows par exemple ?

- Quand cette application est développée en JS, je sais qu'on peut par exemple utiliser Electron. Mais si je ne veux pas utiliser Electron (ou autres outils équivalent embarquant aussi un navigateur) comment on fait ? On utilise un fichier de commande (qui à l'intérieur utilise Node pur exécuter l'application codée en JS) ? Mais là ce qui m'échappent c'est comment on peut coder notre UI (interface utilisateur) ? Si l'UI est codé en HTML/CSS il faudra un navigateur, non ?

- Et si l'application (utilisant des modules Node) est développée en Java par exemple ?

Par exemple pour fixer les idées on analyse le code avec ESlint à l'aide de l'api, on récupère le résultat sous la forme d'un objet ou d'un tableau d'objets et alors on affiche dans la page web des icônes d'erreurs ou d'avertissement à coté des lignes de code...

Ce serait une possibilité ?

Je pense que plutôt que de te poser ces questions, tu ferais mieux de télécharger l'outil et de faire des tests, non ?

Ben j'en ai fait justement avec la ligne de commande et aussi avec l'api Node que ESlint propose.

---> Avec la ligne de commande j'ai vu qu'on pouvait lancer par exemple ceci : eslint file1.js -o report.html -f html ce qui lance l'analyse du code contenu dans le fichier file1.js et écrit les résultats dans le fichier report.html au format HTML.

---> Avec l'api j'ai testé ça :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
var Linter = require("eslint").Linter;
var linter = new Linter();
 
var messages = linter.verify("var foo = function bar() {};", { rules: {/*ici liste des régles*/}});
console.log("msg ----->  " , messages);

[Beginner.]

En faisant quelques recherches sur le sujet je suis tombé sur cet article : Un système pour réaliser des applications en ligne ou hors ligne. Il semble y contenir quelques éléments de réponses, il faut que je regarde ça de plus prés...