Les modules ES6 ?

Version imprimable

14/04/2018, 17h23
Beginner.

Les modules ES6 ?

Salut,

J'ai voulu essayer les fameux modules ES6 (avec chrome 64) mais ce fut sans succès...

Pourtant j'ai cru comprendre que chrome gérait les modules ES depuis la version 61...

Mais après quelques tests je me demande s'il ne faut pas utiliser un serveur ? C'est-à-dire que cela ne fonctionne pas en local ?

Merci.
14/04/2018, 18h25
Marco46

Comment as-tu réalisé l'import de ton source dans Chrome ?

As-tu bien utilisé le type module de cette manière <script type="module" src="module.js"></script> ?

Oui j'ai essayé de reproduire le premier exemple du site : https://jakearchibald.com/2017/es-modules-in-browsers comme ceci :

Dans un fichier html :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>ECMAScript modules in browsers</title> <link rel="stylesheet" href="./../../style.css"> <script type="module" src="index.js"></script> </head> <body> </body> </html>
Le fichier index.js :
Code:

1 2 3 import {addTextToBody} from './utils.js'; addTextToBody('Modules are pretty cool.');
Le fichier utils.js :
Code:

1 2 3 4 5 export function addTextToBody(text) { const div = document.createElement('div'); div.textContent = text; document.body.appendChild(div); }
Et alors je lance chrome (en enlevant la sécurité) et il me dit ceci :

Failed to load module script: The server responded with a non-JavaScript MIME type of "". Strict MIME type checking is enforced for module scripts per HTML spec.

index.js:1

J'ai vu en faisant une recherche que je n'étais pas le seul à avoir ce problème...

14/04/2018, 19h16
Beginner.

Ah j'ai essayé avec l'IDE Cloud9 et ça marche !

Est-ce parce qu'il faut un serveur ?
14/04/2018, 19h17
Marco46
J'ai utilisé ton code tel quel et ça marche très bien.

J'ai simplement ajouté http-server à un package.json :
Code:

1 2 3 4 5 6 7 8 9 10 { "name": "ES6-browser", "scripts": { "start": "http-server -c-1" }, "devDependencies": { "http-server": "^0.11.1" } }
Mon chrome est en version 65.

Quel serveur web utilises-tu ?

Citation:

Et alors je lance chrome (en enlevant la sécurité)

Quelle sécurité ? Pourquoi ?
14/04/2018, 19h18
Marco46

Citation:

Envoyé par Beginner.

Est-ce parce qu'il faut un serveur ?

Pour servir un site web c'est mieux !
14/04/2018, 19h35
Beginner.

Ben justement au début je n'utilisais pas de serveur d'où ma question : "Mais après quelques tests je me demande si il ne faut pas utiliser un serveur ? C'est-à-dire que cela ne fonctionne pas en local ?"

Je croyais qu'on pouvait utiliser les modules ES en local (tous les fichiers dans un répertoire du disque dur) sans serveur comme les codes classiques quoi mais apparemment ce n'est pas possible, c'est ça ?
14/04/2018, 20h23
danielhagnoul

:salut:

Exemple utilisant un module et des Class avec des propriétés "privées" (module) et protégées (get, set).

Nota bene pour les utilisateurs de Firefox

J'ai adopté les modules ES2015 partout, c'est tellement pratique, mais Firefox est en retard par rapport à Chrome et Edge, voir Can I use module : https://caniuse.com/#search=module.
La sortie de Firefox 60 (normal) est prévue pour le 2018-05-09 (https://wiki.mozilla.org/RapidRelease/Calendar)
14/04/2018, 20h52
Beginner.

Merci.
C'est un exemple instructif.

Je vois que tu utilises deux class, c'est intéressant...

Tu utilises les WeakMap pour avoir des variables privées (kNom, kPrix) ?

Mais les autres (kNomType, kPrixType,...) sont aussi privées en quelque sorte puisqu'elles sont dans un module et tout ce qui n'est pas exporté n'est pas accessible depuis l'extérieur du module, non ?

---> Là ça marche car tes fichiers sont dans un serveur mais en local je suppose que cela ne fonctionnerait pas ?

PS : J'ai aussi regardé cet exemple : https://danielhagnoul.developpez.com/Site/QR20180329-1/
14/04/2018, 22h22
Marco46

Citation:

Envoyé par Beginner.

Je croyais qu'on pouvait utiliser les modules ES en local (tous les fichiers dans un répertoire du disque dur) sans serveur comme les codes classiques quoi mais apparemment ce n'est pas possible, c'est ça ?

Apparemment si j'en crois le message d'erreur ce n'est pas possible.

Pour le coup de la security tu as désactivé CORS c'est ça ? C'est mal.

En fait je ne comprends pas pourquoi tu t'acharnes avoir lancer une appli web sans serveur web pour la servir, ça n'a pas de sens.
14/04/2018, 22h48
SylvainPV

Les imports de modules et toute autre requête ne fonctionnent pas avec des fichiers locaux (file://), autrement n'importe quel site pourrait lire tes fichiers, ce qui serait assez problématique question sécurité :aie:
14/04/2018, 23h20
Beginner.

Citation:

Envoyé par Marco46

En fait je ne comprends pas pourquoi tu t'acharnes avoir lancer une appli web sans serveur web pour la servir, ça n'a pas de sens.

Ben l'application il faut bien la mettre au point avant de la servir, non ? Et alors je pensais qu'on pouvait utiliser les module ES durant la phase de développement car pour moi ces modules ben ça permet de travailler sous forme de module justement et on en connait l’intérêt (c'est plus facile de diviser l'application en plusieurs morceaux réutilisables).

Citation:

Envoyé par SylvainPV

Les imports de modules et toute autre requête ne fonctionnent pas avec des fichiers locaux (file://), autrement n'importe quel site pourrait lire tes fichiers, ce qui serait assez problématique question sécurité :aie

Mais pour ça il faudrait qu'il connaisse le nom des fichiers et leur chemin, non ?

- Sinon ben je pensais que c'était comme avec node et les require, ça marche en local, non ? Est-ce parce que node peut lire dans le disque dur ? Mais c'est vrai qu'on doit passer par des bundler (j'avais tester Browserify) pour que ça marche dans un navigateur...

Donc c'est sûr pas moyen de travailler avec les modules en local ? Ah ben voilà encore une raison qui fait qu'on peut encore avoir besoin de rollupjs ???

Du coup comment on fait pour tester durant la phase de développement de l'application (utilisant des modules ES) ? Il faut bien tester avant de mettre ça dans un serveur...

---> Doit-on utiliser un serveur local ?

PS : Ben Daniel comment il a fait ? (Ceci dit c'est vrai que j'ai pu aussi tester avec l'ide cloud9...).
15/04/2018, 01h55
SylvainPV

Citation:

Envoyé par Beginner.

Ben l'application il faut bien la mettre au point avant de la servir, non ?

Tu n'as jamais utilisé de serveur de développement local ? C'est la base, tous les frameworks en proposent un par défaut maintenant, et ils ont plein de fonctionnalités sympas comme le hot reload. Si tu n'utilises pas de framework, je te suggère d'essayer Parcel, dont la doc française vient d'être publiée (votre humble serviteur en est le relecteur) : https://parceljs.org/ ; c'est le bundler le plus simple que je connaisse pour les débutants. Et si tu veux juste un serveur local, sans aucune autre fonctionnalité, alors essaie http-server (voir le post de Marco plus haut) ou https://www.npmjs.com/package/serve ; ce sont deux serveurs locaux basés sur Node.js, très simples d'utilisation là aussi.

Citation:

Envoyé par Beginner.

Mais pour ça il faudrait qu'il connaisse le nom des fichiers et leur chemin, non ?

Ça serait naïf de penser que c'est une sécurité suffisante. Comme laisser sa porte ouverte parce qu'il faudrait que les cambrioleurs connaissent l'adresse.

Citation:

Envoyé par Beginner.

- Sinon ben je pensais que c'était comme avec node et les require, ça marche en local, non ? Est-ce parce que node peut lire dans le disque dur ?

Node est un exécutable comme toute autre appli, pas du tout les mêmes contraintes de sécurité que l'exécution d'un code distant JavaScript dans un navigateur.

Citation:

Envoyé par Beginner.

Mais c'est vrai qu'on doit passer par des bundler (j'avais tester Browserify) pour que ça marche dans un navigateur... Donc c'est sûr pas moyen de travailler avec les modules en local ? Ah ben voilà encore une raison qui fait qu'on peut encore avoir besoin de rollupjs ???

Mais si, les modules ES6 fonctionnent très bien en local, à condition de passer par un serveur local et pas de lire directement dans le système de fichiers.
15/04/2018, 18h43
Beginner.

Merci.

Oui j'avais entendu parlé de Parcel mais j'avais mal compris car j'avais cru comprendre qu'il ne gérait pas les modules ES mais apparent c'est le cas ??? Il gère même les modules de Node apparemment ?

J'ai cru comprendre qu'il était simple d'utilisation car il ne nécessite pas de configuration mais on peut regretter le tree shaking de Rollup... Mais peut-être qu'il sera implémenté dans Parcel : https://github.com/parcel-bundler/parcel/issues/392 ?
20/04/2018, 19h11
frfancha

Citation:

Envoyé par SylvainPV

Les imports de modules et toute autre requête ne fonctionnent pas avec des fichiers locaux (file://), autrement n'importe quel site pourrait lire tes fichiers, ce qui serait assez problématique question sécurité :aie:

Pas tout-à-fait: le browser pourrait très bien limiter l'utilisation de file:// aux html ou modules chargés localement.
20/04/2018, 20h16
SylvainPV

Comment ça, aux modules chargés localement ? Le browser limiterait l'import de modules aux modules déjà chargés ? :weird:
Quant au HTML, le navigateur ne se base pas sur l'extension pour détecter le type d'un fichier mais sur le mime type, ce qui impliquerait d'accéder en lecture à tous les fichiers pour obtenir leur type. Et même si on trouvait un moyen de restreindre aux fichiers HTML, cela outrepasse déjà largement les règles de sécurité élémentaires.
24/04/2018, 14h13
frfancha

Cette discussion est théorique est sans vraiment d'importance, mais pas d'accord:
le browser pourrait très bien admettre le file protocol à partir des html qui ont été chargés par ce même protocol
Cela ne pose aucun problème de sécurité
En fait c'est un peu du même origine checking où "file://" serait considéré comme une origine
24/04/2018, 16h56
SylvainPV

Cela voudrait dire que si tu ouvres un fichier HTML en local avec file://, alors il serait capable de lire tout ton disque dur et d'envoyer le tout à un serveur distant ? C'est un léger problème de sécurité pour moi quand même :mrgreen:
Aussi file:// est un protocole, pas une origine, donc la comparaison ne tient pas. Sinon n'importe quel site pourrait aller requêter n'importe quel autre sous prétexte qu'ils sont tous les deux en http://