Travailler sous forme de projet (avec plusieurs fichiers .js) ?

Ok merci.

J'étais en train de regarder cet article (ici) qui fait une comparaison, rollups produit un fichier moins gros que browserify (33% moins gros dans son exemple)...

Et je lis aussi ceci : In a future post I will do more exploring with Rollup and look at how we’d configure it on a much larger project that contains npm dependencies, and modules written in CommonJS (that Rollup, without a plugin) can’t parse.

Apparemment cela confirme qu'on ne peut pas (sans plugin) travailler avec les modules de node...

Oui il faut ajouter ce plugin : https://github.com/rollup/rollup-plugin-commonjs

Mais c'est un détail mineur, puisque la plupart des dépendances NPM destinées à être utilisées côté navigateur sont déjà proposées sous la forme de bundle ou de module ES6. Donc bien souvent, on a même pas besoin de ce plugin.

C'est le même genre de discussion qui pousse au retard de l'intégration des modules sur Node; certains veulent absolument être parfaitement interopérables entre CommonJS et modules ES, quitte à dévier de la spec standard et à changer d'extension de fichier, alors que c'est un faux-problème qu'on a résolu depuis des années avec l'outillage existant.

Ok merci.

Citation:

---

Envoyé par SylvainPV

Comme dit plus haut, je te conseille d'oublier browserify et require(), les modules CommonJS sont obsolètes maintenant que les modules ECMAScript sont là.
Regarde plutôt du côté de https://rollupjs.org/ , en plus les sourcemaps sont gérées par défaut.

---

Salut,

Je remonte ce fil pour demander si rollupjs est toujours utile ou bien si il est aussi obsolète étant donné que les modules ES6 sont déjà gérés nativement par plusieurs navigateurs ?

Ceci dit en admettant qu'il soit obsolète ou qu'il le sera peut-être, peut-il être utile pour d'autres choses ?

- Par exemple mettre tous les script dans un seul fichier ? Et j'ai cru comprendre que seul le code effectivement utilisé se retrouvait dans ce fichier (bundle).

Merci.

Bonne question, et la réponse est oui, les bundlers sont toujours utiles et nécessaires. Sans même parler du support navigateur qui est loin d'être parfait, les benchmarks ont montré que les bundles sont plus performants que le chargement direct de modules depuis le navigateur, même avec HTTP/2 Push. De plus, les process de dev front modernes embarquent tous une phase de compilation, pour le bundling mais aussi pour l'analyse qualité code (ESLint), le code style (Prettier), les post-optimisations (tree-shaking, code splitting, et dans un avenir proche, Prepack) et tous les autres usages de transpilation (Babel, TypeScript etc...). Et cette compilation est de plus en plus rapide et de moins en moins handicapante avec les progrès apportés aux bundlers et le rechargement de modules à chaud. C'est plus ou moins devenu la norme pour le dev JavaScript en 2018, il va falloir s'y faire. Mais on peut éventuellement utiliser le support des modules dans le navigateur pour du quick prototyping.

Un article en anglais avec plus d'infos : https://www.contentful.com/blog/2017...hink-bundling/

Ok merci.

Je regarderai l'article dont tu donnes le lien...

Sinon j'ai voulu essayer les modules ES6 et ça ne fonctionne pas !!!
Mais je vais ouvrir un autre fil...

Citation:

---

Envoyé par SylvainPV

Oui Node.js retarde l'adoption des modules ES6 à cause de débats stériles sur la manière de les intégrer avec l'écosystème existant (CommonJS). Mais ce n'est pas un problème vu qu'on a l'outillage pour passer d'un format à l'autre très facilement. Aussi, hier on a annoncé un moyen de supporter les modules ES dans Node : https://medium.com/web-on-the-edge/e...ay-32cff914e4b

---

Je reviens sur ce point car j'ai cru comprendre que Node supporte les modules ES6 nativement maintenant : Using ES modules natively in Node.js ?

Mais en fait il faut utiliser l'extension .mjs mais je ne sais plus où j'ai lu ça mais je crois qu'il doit y avoir encore une évolution ce mois-ci ?