Discussion :

[JackStrieger]

Bonjour à tous !

Je ne sais pas trop où poster ce message, j'ai hésité entre javascript et nodejs, mais je ne suis pas sur que ce soit approprié.

Je commence en ce moment un projet, et j'ai installé webpack (https://github.com/symfony/webpack-encore) pour la minification js, et la compilation sass en css. Le projet se fait aussi en utilisant bootstrap, et jquery qui va avec pour la partie js.
Je me retrouve avec ce problème :

jQuery.Deferred exception: $(...).tooltip is not a function ./assets/js/main.js/</<@http://sandbox._.dev/build/js/main.js:77:5
mightThrow@http://sandbox._.dev/build/js/main.js:3624:21
resolve/</process<@http://sandbox._.dev/build/js/main.js:3692:12
undefined
jquery.js:3818
TypeError: $(...).tooltip is not a function
[En savoir plus]

Webpack isole donc le build de l'extérieur, donc bootstrap n'est pas accessible.
Est-on d'accord que require importe tout le contenu du fichier source dans le build ?
Si c'est le cas, c'est problématique de faire un require dans chaque fichier parce que cela prend faire du code dupliqué dans chaque fichier buildé.

Avez vous des manières de faire sur vos projets pour ce genre de problèmes ?

[Marco46]

Je ne sais pas trop où poster ce message, j'ai hésité entre javascript et nodejs, mais je ne suis pas sur que ce soit approprié.

C'est très bien ici, webpack c'est plutôt pour générer des livrables fronts (même si ça reste un programme node).

Je me retrouve avec ce problème

$(...).tooltip is not a function

A la lecture du message j'ai l'impression qu'il cherche le tooltip de jQuery-ui dans jQuery.

Webpack isole donc le build de l'extérieur, donc bootstrap n'est pas accessible.

Je ne comprends pas. Webpack prend le point d'entrée de ton appli et descend dans la hiérarchie via les require. Si bootstrap n'est jamais require il va y avoir un soucis.

T'aurais pas un soucis de config ?

Si c'est le cas, c'est problématique de faire un require dans chaque fichier parce que cela prend faire du code dupliqué dans chaque fichier buildé.

Non si tu require lodash dans 3 fichiers sources différents il n'importe pas 3 fois lodash, seulement une fois. Ou alors j'ai mal compris ce que tu voulais dire.

[JackStrieger]

Je te remercie pour ton message, surtout le dernier point qui m'éclaire pas mal dans mes questionnements par rapport à webpack.

Alors pour le tooltip (qui est un tooltip bootstrap), il n'était pas disponible parce que je ne faisais pas de require de bootstrap dans le fichier. Après le require ça fonctionne bien, mais cette méthode ne me convenait pas forcément, j'explique plus bas pourquoi. Par ailleurs, après avoir cherché, j'ai vu qu'on pouvait exposer des fonctions avec webpack afin qu'ils soient disponibles à l'extérieux et ça ça peut être intéressant pour ce que je souhaite !

Plus concrètement, l'un des besoins est d'avoir une application qui soit le moins lourd possible. J'ai donc fait le choix de ne pas avoir un un seul fichier js avec tout le js minimifié dedans. Mais plutôt d'avoir un fichier js minimifié avec les libs utilisées partout (bootstrap, jquery, ...) et un fichier avec seules les fonctions utilisées sur la page. Ce qui revient à avoir un fichier js par page concrètement.

Donc je me demandais comment je pourrais utiliser les fonctions des libs dans d'autres fichiers. Et je me demandais comment faisaient les autres sur d'autres projets qui ne soient ni en SPA, ni en un fichier min.

En tout cas merci pour ton aide !

[Marco46]

Plus concrètement, l'un des besoins est d'avoir une application qui soit le moins lourd possible. J'ai donc fait le choix de ne pas avoir un un seul fichier js avec tout le js minimifié dedans. Mais plutôt d'avoir un fichier js minimifié avec les libs utilisées partout (bootstrap, jquery, ...) et un fichier avec seules les fonctions utilisées sur la page. Ce qui revient à avoir un fichier js par page concrètement.

Je pense que c'est une erreur de vouloir faire ça. Tu vas te compliquer la vie pour rien et ça va être un enfer à maintenir.

La meilleure façon de procéder c'est d'avoir un seul bundle contenant absolumeent tout. Avec le tree shaking, Webpack est capable de n'ajouter au bundle que les parties de tes dépendances (et même de ton code) qui sont require (alors en fait il faudrait que tu utilises les imports ES6 pour ça, et pas le require de CommonJS, mais la refacto peut valoir le coup !). Donc en gros si bootstrap minifié fait 500ko (je dis n'importe quoi sur les valeurs), mais que tu n'utilises que pour 50 ko de la lib, Webpack est capable de n'importer que les 50 ko nécessaire en descendant dans les require.

Par ailleurs, n'oublie pas que les navigateurs ont une gestion du cache, donc un utilisateur ne téléchargera qu'une seule fois le bundle. Alors que si tu commences à faire un bundle dédié par page tu vas lui faire télécharger autant de bundle qu'il n'a de pages ...

EDIT : Si ton sujet est résolu de ton point de vue merci de marquer le sujet comme tel !

[JackStrieger]

Merci pour cet avis ! C'est exactement ce que je cherchais, je ne connaissais pas le tree shaking !

[Marco46]

Attention pour bénéficier du tree shaking il faut absolument utiliser la syntaxe des modules ES6 et le destructuring :

Code :

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

1
2
 
import { fonctionA, fonctionB, fonctionE } from './module.js';

et non la syntaxe CommonJS :

Code :

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

1
2
 
const module = require('module');

Grace au destructuring, Webpack sait quels morceaux du module ton appli utilise, et c'est comme ça qu'il peut choisir ce qu'il importe dans son bundle.

Donc ça peut imposer un refactoring important pour passer de CommonJS aux modules ES6.

[Tony310]

En complément, tu peux également ajouter un analyseur de bundle (webpack-chart, webpack-visualizer ou webpack-bundle-analyzer). Celui-ci te détaillera finement la part de chaque module dans la taille totale de ton bundle.
On peut avoir de grosses surprises, ou observer un mauvais comportement du tree shaking (pas forcément dû à webpack, mais aussi à la librairie utilisée). Il est parfois nécessaire de modifier un peu ses import (ou sa conf webpack) pour que seuls les bouts de codes vraiment utilisés soient importés.

Pour ta problématique de séparation en différents fichiers chargés au bon moment, peut être que ceci pourra t'aider :
https://webpack.js.org/guides/code-splitting/
https://webpack.js.org/guides/lazy-loading/

[JackStrieger]

Je te remercie pour ces infos, je vais y jeter un coup d'oeil !

[Beginner.]

Salut,

Merci ce fil est intéressant...

Sinon moi aussi quand j'ai commencé à découvrir les bundlers je me suis demandé si on pouvait avoir plusieurs bundles... Mais bon je n'ai pas encore le niveau pour utiliser ces outils... Je cherche encore à comprendre certaines choses...

Attention pour bénéficier du tree shaking il faut absolument utiliser la syntaxe des modules ES6 et le destructuring :
(...)
Donc ça peut imposer un refactoring important pour passer de CommonJS aux modules ES6.

Merci.

- Oui il m'avait bien semblé avoir compris ça et justement une chose me turlupine : on peut utiliser les modules ES6 dans nos codes mais qu'en est-il du code écrit pas d'autres et utilisant les modules CommonJS ? Je pense en particulier aux nombreux modules Node, est-ce que cela fonctionne avec derniers ?

Est-ce qu'il suffit d'utiliser des import à la place des require même si à la base le module est de type CommonJS ? Si oui alors est-ce que c'est suffisant de faire ça pour le module "principale" ou bien il faut aussi le faire avec toutes ses éventuelles dépendances ?

- Une autre chose qui me turlupine c'est l'usage de babel, j'ai cru comprendre qu'entre autres "il transformait les modules ES6 en modules CommonJS" (je ne sais pas si c'est correcte de le dire comme ça mais j’espère être compris quand même)... Aors si c'est bien le cas est-ce que cela ne posera pas un problème ?

Questions complexes mais je les pose quand même au cas où...
Merci.

[Marco46]

- Oui il m'avait bien semblé avoir compris ça et justement une chose me turlupine : on peut utiliser les modules ES6 dans nos codes mais qu'en est-il du code écrit pas d'autres et utilisant les modules CommonJS ?

Je pense que c'est mort dans ce cas de figure.

Je pense en particulier aux nombreux modules Node, est-ce que cela fonctionne avec derniers ?

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.

Est-ce qu'il suffit d'utiliser des import à la place des require même si à la base le module est de type CommonJS ?

Non il faut que le package supporte les modules ES6. Enfin à ma connaissance je peux me tromper j'avoue n'avoir jamais essayer de faire ça mais je vois pas comment ça pourrait fonctionner.

- Une autre chose qui me turlupine c'est l'usage de babel, j'ai cru comprendre qu'entre autres "il transformait les modules ES6 en modules CommonJS" (je ne sais pas si c'est correcte de le dire comme ça mais j’espère être compris quand même)... Aors si c'est bien le cas est-ce que cela ne posera pas un problème ?

Babel permet de viser l'ES5 pur. Le tree shaking s'il opère avant la transpilation devrait fonctionner sans soucis. Là aussi c'est théorique je n'ai jamais mis ça en pratique (Babel + Webpack) mais je vois pas pourquoi ça marcherait pas.

Donc en gros si tu fais dans cet ordre ES6 -> tree shaking -> Babel vers ES5 il ne devrait pas y avoir de soucis.

[Beginner.]

Merci.

--- Première partie transférée ici : Comment utiliser les outils (codes) disponibles sous forme de module/package Node ?

Babel permet de viser l'ES5 pur. Le tree shaking s'il opère avant la transpilation devrait fonctionner sans soucis. Là aussi c'est théorique je n'ai jamais mis ça en pratique (Babel + Webpack) mais je vois pas pourquoi ça marcherait pas.

Donc en gros si tu fais dans cet ordre ES6 -> tree shaking -> Babel vers ES5 il ne devrait pas y avoir de soucis.

Ah ok, je pensais à ça aussi... Sais-tu si c'est ainsi que procède Webpack ?

Désolé pour les questions un peu complexes...

[Marco46]

C'est pas que les questions sont complexes c'est que j'ai jamais expérimenté directement ces cas de figure. J'ai très peu de pratique avec Webpack, je te répond "en théorie" en fonction de ce que j'ai compris de l'outil. A mon avis, Webpack procède comme on lui dit de procéder, c'est une question de config donc.