Après Parcel j’ai testé Webpack et autant le dire tout de suite, c’est pas concluant sauf que…
Je suis tout de même arrivé à mes fins avec une installation globale des modules Node — merci Yarn —pnp suggéré par @ldbglobe que je remercie — et à produire un fichier CSS à partir du fichier Sass, par contre pas moyen de trouver, pour l’instant, comment minifier le résultat (j’ai du louper le plugin qui va bien).
Pour l’instant mon fichier package.json ressemble à ça :
{
"name": "ensemble",
"version": "1.0.0",
"description": "Dotclear 2 theme",
"scripts": {
"build": "webpack"
},
"repository": {
"type": "git",
"url": "git+https://github.com/franck-paul/ensemble.git"
},
"keywords": [],
"author": "Franck Paul and contributors",
"license": "GPL-2.0",
"bugs": {
"url": "https://github.com/franck-paul/ensemble/issues"
},
"homepage": "https://github.com/franck-paul/ensemble#readme",
"preferGlobal": true,
"dependencies": {
"webpack": "^5.28.0",
"webpack-cli": "^@4.5.0",
"mini-css-extract-plugin": "^1.4.0",
"sass-loader": "^@11.0.1",
"css-loader": "^@5.2.0",
"sass": "^@1.32.5"
},
"installConfig": {
"pnp": true
}
}
Et le fichier de configuration de Webpack à ceci :
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
module.exports = {
entry: ['./src/scss/main.scss'],
output: {
filename: 'main.css',
},
optimization: {
minimize: true,
},
module: {
rules: [
{
// regular css files
test: /\.css$/,
use: [MiniCssExtractPlugin.loader, { loader: 'css-loader', options: { url: false, sourceMap: true } }],
},
{
// sass / scss loader for webpack
test: /\.(sass|scss)$/,
use: [
MiniCssExtractPlugin.loader,
{ loader: 'css-loader', options: { url: false, sourceMap: true } },
{ loader: 'sass-loader', options: { sourceMap: true } },
],
},
],
},
plugins: [
new MiniCssExtractPlugin({
filename: 'style.css',
}),
],
devtool: 'source-map',
mode: 'none',
};
Avec ça un yarn build produit un résultat dans le répertoire dist, ce que je cherche à faire, sauf qu’il me crée deux fichiers CSS (avec leur map respective), un nommé style.css avec l’intégralité de la CSS utilisable, je ne vais pas le reproduire ici, ça serait inutile et un second nommé main.css qui contient ça :
/******/ (() => { // webpackBootstrap
/******/ "use strict";
/******/ // The require scope
/******/ var __webpack_require__ = {};
/******/
/************************************************************************/
/******/ /* webpack/runtime/make namespace object */
/******/ (() => {
/******/ // define __esModule on exports
/******/ __webpack_require__.r = (exports) => {
/******/ if(typeof Symbol !== 'undefined' && Symbol.toStringTag) {
/******/ Object.defineProperty(exports, Symbol.toStringTag, { value: 'Module' });
/******/ }
/******/ Object.defineProperty(exports, '__esModule', { value: true });
/******/ };
/******/ })();
/******/
/************************************************************************/
var __webpack_exports__ = {};
__webpack_require__.r(__webpack_exports__);
// extracted by mini-css-extract-plugin
/******/ })()
;
/*# sourceMappingURL=main.css.map*/
Vu de chez moi ça ne ressemble pas trop à du CSS ça, et je n’ai aucune idée de son objet ! En fait, vu d’ici on dirait du Javascript, mais je peux me tromper, hein ?
Est-ce un fichier intermédaire ? Mais dans ce cas pourquoi générer un fichier .css.map, ou alors Webpack ne finit pas correctement son job, mais je ne saurais dire pourquoi.
Je sais par ailleurs que les deux voire trois autres outils que j’ai en vue, Gulp, Grunt et Rollup tournent aussi avec Node et je ne vais donc pas pouvoir y échapper. Par ailleurs, il semble que malgré la possibilité d’installer ces outils de manière globale, il n’est quasiment pas possible de les utiliser autrement qu’en les installant localement.
Bref, vais-je devoir me contraindre à installer tout ça localement, quitte, comme me le suggérait hier Olivier, à prévoir un Makefile qui fasse le ménage des modules Node une fois le build effectué ?
Comme le mentionnait ldbglobe dans son commentaire sur mon retour d’expérience avec Parcel, en utilisant une installation globale je prends le risque d’une incompatibilité inter-projet, ce qui est vrai dans l’absolu sauf à considérer que l’essentiel sinon la totalité des projets que je développe et/ou maintiens concerne un écosystème homogène, celui de Dotclear, ce qui justifie, à mes yeux, une installation globale — quitte d’ailleurs à installer localement pour un projet externe.
Quant à la doc de Webpack et de ses zilliards de plugin, j’avoue avoir eu du mal en ce qui concerne la mise en œuvre, en particulier quand j’ai cherché comment assurer la minification de la feuille de style avec le passage de Sass à CSS. Ou alors c’est encore un autre plugin tiers qui s’occuperait de ça et pas ceux mis en œuvre… ?
Comme pour Parcel, l’essentiel des tutos, documentations, articles, concernent un usage « non-exotique », contrairement à ce que je fais.
J’hésite un peu sur la direction à prendre :
- Installer localement et reprendre depuis le début, éventuellement en refaisant des tests avec Parcel puis avec Webpack.
- Continuer mes tests avec Gulp, Grunt et Rollup histoire d’être exhaustif.
- La réponse 3.
:-)
1 De Philippe -
Tu as oublié la réponse 4 : Stéphanie de Monaco ;)
2 De Nicolas -
Je ne comprends pas ta volonté (ou ton besoin comme tu préfères) de ne pas installer les dépendances localement au projet. Quel est le soucis ? De toute façon le répertoire node_modules n’est pas historisé dans git. Qu’est-ce que j’ai raté ?
3 De Franck -
Nicolas, dépendances installées localement, souvent pas loin de 200Mo, multiplié par le nombre de projets, environ une centaine, on arrive à 20Go de bordel dupliqué sur le disque dur et mon disque ne fait pas 10 zilliards de tera-octets :-)
4 De Biou -
Effectivement ce qui est complexe avec Webpack c’est de trouver les bons plugins, de bien les configurer et de bien les câbler entre eux.
Pour aller dans le sens de Nicolas et de Ldbglobe, tu peux faire un monorepo avec tes projets en sous-dossiers et avoir un seul package.json.
Versionner le package.json permet aux autres contributeurs d’utiliser exactement la même version des outils que toi.
5 De Franck -
J’avoue que j’ai un peu de mal avec le « versionning » des outils de build ; l’idée n’étant pas d’utiliser ce qui se fait de mieux en la matière, donc je suppose le plus récent ?
Sinon un projet vieillit si tout est installé localement et que ses dépendances sont réglées sur des versions spécifiques des outils ; quid des bugs trouvés dans ceux-ci, …
J’imagine, hein ? C’est un eco-système dont je ne suis absolument pas familier ; il y a peut-être un paradigme que j’ai squizzé…
6 De Nicolas -
L’avantage de figer les versions des outils est que tu as la garantie que ça fonctionnera toujours pareil (au détail près que tu puisses toujours récupérer les versions que tu précisées) et comme dit biou tout ceux qui contribue au projet auront les mêmes versions. Tu ne devrais pas avoir d’effet “© chez-moi-ça-marche”
Et pour l’histoire de la place occupée rien ne t’interdit de supprimer le répertoire node_modules quand tu ne bosses plus sur le projet. De toute façon npm (ou yarn) crée un cache des modules téléchargés.
7 De Mathieu -
Si l’idée c’est de gérer les problématiques de compilation sass il reste possible de coder à moindre frais un outil avec du nodejs de base et comme seule package node-sass https://www.npmjs.com/package/node-sass. Résultat un outil plus léger et librement adaptable
8 De Franck -
Mathieu pas seulement, et par ailleurs on fait déjà ça pour construire les CSS de l’admin et celle du thème Berlin de Dotclear (avec Compass/Sass).
Par ailleurs on minifie aussi les Js à la livraison, en utilisant un minifier PHP, mais ça reste un peu artisanal.