Étiquette : Grunt

[Magento 2] Exploiter la fonctionnalité CSS critical path avec un fichier LESS (via Grunt)

Versions de Magento 2.3.3+: Petit topo sur le CSS critical path dans la doc front-end officielle.

La fonctionnalité est limitée, nativement, à l’utilisation d’un fichier au format CSS (pas de LESS).

Pour contourner cette limitation, créez un fichier critical.less dans app/design/frontend/Vendor/theme/web/css/critical.less et déclarez ce dernier dans votre config Grunt (dev/tools/grunt/configs/local-themes.js):

Puis lancez les commandes:

[Magento 2] Utiliser Grunt pour compiler les assets front-end

Difference between static content deploy & grunt exec.

Utilisation de Grunt lorsque le mode developer de Magento 2 est activé

Activer le mode developer de Magento 2

Activer le mode Developer de Magento 2: $ bin/magento deploy:mode:set developer.

Se rendre en backoffice dans Stores > Configuration [Settings] > ADVANCED > Developer. Dans Frontend Development Workflow > champ Workflow type > sélectionner « Client side less compilation » (au besoin, décocher la case « Use system value »). Bouton « Save Config » en haut à droite.

Préparer les fichiers de config nécessaires à l’utilisation de Grunt dans Magento 2

$ cp package.json.sample package.json; cp Gruntfile.js.sample Gruntfile.js; cp grunt-config.json.sample grunt-config.json; cp dev/tools/grunt/configs/themes.js dev/tools/grunt/configs/local-themes.js

Nous allons partir du principe que nous utilisons Grunt pour processer les fichiers source d’un thème enfant « luma-child ». C’est la raison pour laquelle nous créons un fichier dev/tools/grunt/configs/local-themes.js qui contient donc ceci:

Lancer les tâches Grunt et commencer à développer

Lancer la commande $ grunt clean && grunt exec && grunt watch. Lorsque Grunt est arrivé au bout des tâches clean, et exec, la tâche watch débute et vos fichiers sont surveillés. Désormais, à chaque fois que vous souhaiterez tester une modification en front pendant que la tâche watch tourne, il faudra lancer la commande $ rm -rf pub/static/*; rm -rf var/view_preprocessed/* avant de rafraîchir la fenêtre de votre navigateur.

Remarque: si vous rencontrez une erreur (dans l’exécution des tâches précédant le grunt watch) qui stoppe le process, le grunt watch ne fonctionnera pas correctement.

Remarque #2: la tâche $ grunt watch semble fonctionner uniquement si elle est exécutée précédée des tâches $ grunt clean && grunt exec.

Remarque #3: pour la surveillance des fichiers *.less, elle semble concerner l’ensemble des fichiers présents dans le scope du dossier /app/design/frontend/<Vendor>/theme/web/css/source. Autrement dit, pas besoin de déclarer ces fichiers dans /dev/tools/grunt/configs/local-theme.js. Exemple ci-dessous avec un thème luma_child:

A savoir: La présence des fichiers css/styles-m et css/styles-l n’est pas obligatoire dans votre thème, mais les déclarer dans votre fichier /dev/tools/grunt/configs/local-theme.js permet à Grunt de bien prendre en compte les fichiers de base d’un thème Magento 2 (_theme.less, _extend.less, etc…). J’ai eu, par exemple, un cas où la tâche grunt watch ne surveillait pas le code que j’écrivais et les fichiers que j’importais depuis le fichier natif _extend.less dans mon thème enfant. Après avoir signalé la présence des fichiers css/styles-m et css/styles-l dans mon fichier /dev/tools/grunt/configs/local-theme.js, le fichier _extend.less et tous les fichiers importés depuis ce dernier étaient surveillés.

Créer une tâche custom dans Grunt

Testé fonctionnel. Source: How to create a custom Grunt task in Magento 2 et version PDF pour la postérité.

Ajouter un plugin pour grunt-contrib-less

Attention: WiP pas fonctionnel

Attention #2: pensez à vérifier la compatibilité de votre plugin avec la version de grunt-contrib-less déclarée dans le fichier package.json à la racine de votre projet Magento 2!

$ npm install --save-dev less-plugin-lists

Modifier <project_root_folder>\dev\tools\grunt\configs\less.js en déclarant le plugin less-plugin-lists via l’option plugins de grunt-contrib-less:

$ grunt clean && grunt exec && grunt less && grunt watch

Supprimer la sous-tâche Grunt less:documentation du process de compilation des assets front-end de Magento 2

Lorsque le process Grunt en arrive à la sous-tâche less:documentation, j’obtiens ce message d’erreur (Magento 2.3):

Il s’agit d’une variable less qui n’est pas définie. On peut donc corriger les fichier less en définissant cette variable manquante, mais on peut aussi supprimer la sous-tache Grunt qui consiste à générer la documentation. Pour ce faire, éditer le fichier dev\tools\grunt\configs\less.js pour mettre les lignes suivantes en commentaire:

Ne pas compiler certains thèmes

Dans le fichier dev/tools/grunt/configs/less.js, ajouter une condition à la fonction _each et y lister les thèmes qui ne doivent pas être compilés:

Grunt dans Magento 2 – Troubleshooting

Erreur SyntaxError: unexpected token -" au lancement d’une tâche Grunt

ATTENTION: n’utilisez pas le caractère « tiret du 6 » (-) pour déclarer le libellé du thème dans le fichier dev/tools/grunt/configs/local-themes.js; préférez l’underscore (_) pour ne pas obtenir l’erreur SyntaxError: unexpected token -" au lancement de vos tâches Grunt!

Example de mauvaise pratique dans la déclaration d’un thème:

Example de bonne pratique dans la déclaration d’un thème:

En backoffice, la colonne de gauche est tassée

Les libellés des onglets s’affichent un caractère par ligne. Solution: lancer les processes Grunt avec la commande $ grunt clean && grunt exec && grunt less && grunt watch. Laisser terminer. Lorsque Grunt est en watch, taper dans un terminal la commande de suppression des fichiers statiques: $ rm -rf pub/static/*; rm -rf var/view_preprocessed/*. Rafraîchir votre page.

[Magento 2] Bonnes pratiques et astuces de développement front-end

Les commandes Magento 2 du développeur Front-End

Disponibles ici: Commandes Magento 2 Magerun développeur front-end.

Installation des sample datas: comment se logger sur repo.magento.com pour Composer ?

Problème: j’essaye d’installer les sample datas de Magento 2 via Composer, mais lorsque je tape la commande $ bin/magento sampledata:deploy, j’obtiens un message Authentication required (repo.magento.com): Username Password.

Solution: Il faudra créer un compte sur marketplace.magento.com et récupérer le login (clé publique) et le mot de passe (clé privée) sous My Profile > My Products > Access Keys. Il sera peut-être nécessaire de générer une paire de clé.

Le Username demandé correspond à la clé publique. Le Password demandé correspond à la clé privée. Et PAS aux username et password de votre compte marketplace.magento.com!

Ajouter un nouveau module à votre projet Magento 2

En ligne de commande: $ n98-magerun2 dev:module:create

Ajouter un nouveau thème à votre projet Magento 2

Fichiers à préparer

Partir d’un thème Luma Child

Tips: les sources d’un starter-theme Luma Child sont disponibles en suivant ce lien.

Partie conf à ajouter dans <project_root>\dev\tools\grunt\configs\local-themes.js:

Partir from-scratch

Sinon, si vous souhaitez débuter +/- from-scratch, vous pouvez suivre la documentation officielle de Magento 2 pour créer un nouveau thème.

Différentes manipulations à effectuer et commandes à exécuter

Dans cet ordre (et PAS dans un autre ordre, sinon ça ne fonctionne pas) :

  1. Ajouter le dossier du nouveau thème dans: app/design/frontend/<Vendor_name>/<theme_name>
  2. Mettre à jour le nouveau thème dans l’interface admin: Content > Design > Configuration > (Select Edit on your Store View) > Default Theme > Applied Theme > "<your_new_theme_name>"
  3. Flusher les caches avec la commande: $ n98-magerun2 cache:flush
  4. Lancer les commandes Grunt: $ grunt clean && grunt exec && grunt less && grunt watch
  5. Vider les caches statiques des thèmes: $ rm -rf pub/static/*; rm -rf var/view_preprocessed/
  6. Vous pouvez rafraîchir votre navigateur: ctrl + F5

Styles et héritage

Deux notions bien distinctes à intégrer: l’extension et la surcharge de styles.

Extension (extend) des styles

L’extension permet de conserver, pour le fichier qui est étendu, les styles déclarés dans le(s) thème(s) parent(s) et d’en écrire des supplémentaires. Cette méthode est pratique lorsque votre thème hérite d’un thème parent dont les styles vous conviennent déjà. Elle s’utilise pour apporter des modifications mineures à l’existant.

Surcharge (override) des styles

La surcharge écrase, pour le fichier qui est surchargé, l’intégralité des styles déclarés dans le(s) thème(s) parent(s) pour repartir d’une base neutre. Cette dernière demande beaucoup plus de travail côté front-end.

Override et déclaration de nouvelles variables less

Tips: Magento naming convention for the Less variables et Modifier les valeurs des variables par défaut d’un thème parent (blank/luma).

Ce qu’il faut retenir:

  • Pour surcharger les valeurs de variables existantes et déclarées dans un thème parent, il faut surcharger le fichier _theme.less. Ce fichier doit contenir uniquement des déclarations concernant des variables déjà existantes dans des thèmes parents.
  • Pour déclarer de nouvelles variables propres à votre thème enfant, il faut créer un nouveau fichier. Vous avez le choix entre:
    • Créer un fichier _variables_extend.less qu’il faudra importer depuis le fichier _extend.less
    • ou créer un fichier qui peut s’appeler comme vous voulez (à part _variables.less qui va faire exploser votre affichage!) et dans lequel vous consignerez vos nouvelles variables

Héritage des thèmes dans Magento 2: Luma < (hérite de) Blank < (hérite de) Core.

  • vendor/magento/theme-frontend-luma/web/css/source/_theme.less
    • Contient uniquement des surcharges de variables ayant déjà été déclarées dans les fichiers .less du Core (cf. lib/web/css/source/lib/_variables.less).
  • vendor/magento/theme-frontend-luma/web/css/source/_variables.less
    • Contient des surcharges de variables ayant déjà été déclarées dans le/les thème(s) parent(s) (Blank < Core), ainsi que de nouvelles variables qui seront exploitées dans plusieurs fichiers du thème Luma.
    • Ce fichier n’a pas l’air surchargeable dans un theme qui serait enfant de Luma (héritage: Luma Child < Luma < Blank < Core). Il faut obligatoirement l'étendre en créant un nouveau ficher app/design/frontend/<Vendor_name>/<Luma_child_theme_name>/css/source/_variables_extend.less, lui-même importé via @import '_variables_extend.less'; depuis app/design/frontend/<Vendor_name>/<Luma_child_theme_name>/css/source/_extend.less.
    • Ce fichier n’a pas l’air d’avatage surchargeable dans un theme qui serait simplement enfant de Blank (héritage: Blank Child < Blank < Core). Il faut obligatoirement l'étendre en créant un nouveau ficher app/design/frontend/<Vendor_name>/<Blank_child_theme_name>/css/source/_variables_extend.less, lui-même importé via @import '_variables_extend.less'; depuis app/design/frontend/<Vendor_name>/<Blank_child_theme_name>/css/source/_extend.less.
  • vendor/magento/theme-frontend-luma/web/css/source/_forms.less contient de nouvelles variables qui seront exploitées uniquement dans ce fichier.

vendor/magento/theme-frontend-luma/web/css/source/_variables.less

Luma nous donne un bon exemple de comment doit être organisée cette feuille de styles. Les grandes parties (Typography, Icons, …) contiennent des surcharges des valeurs de variables existantes déclarées respectivement au minimum dans lib/web/css/source/lib/variables/_typography.less et dans lib/web/css/source/lib/variables/_icons.less.

« Au minimum«  car elles peuvent déjà être surchargées une première fois dans le thème Blank (intermédiaire). @font-family-name__base est, en effet, déclarée pour la première fois dans vendor/magento/theme-frontend-blank/web/css/source/_variables.less.

vendor/magento/theme-frontend-luma/web/css/source/_forms.less

Aliases

Une série d’aliases à ajouter au fichier .bashrc.

  • Pour éditer le fichier: $ vim ~/.bashrc
  • Pour valider les changements sans quitter le terminal: $ source ~/.bashrc

[Docker] Utiliser node, npm, grunt, gulp, webpack, bower, yarn, etc.

Docker for Gulp Build Tasks et version PDF pour la postérité. Cet article m’a permis de mettre en place un Docker pour compiler mes sources Front-End via NPM (workflow utilisant Bower et Gulp). Et ça marche!!!


Mes sources pour ce billet:


Avec Foundation Zurb Template

Création de la Dockerfile

Dans home/intlangf/docker/ je fais un git clone https://github.com/zurb/foundation-zurb-template.git fzt (pour récupérer les sources du framework CSS Foundation).

Ensuite, cd fzt pour entrer dans le dossier créé par Git. Puis touch Dockerfile et vim Dockerfile pour créer et éditer un fichier Dockerfile dans lequel je place le code ci-dessous:

Builder le container

Pour builder le container (que je vais appeler « fzt »), j’exécute la commande: docker build -t fzt .

Exécuter une commande à l’intérieur du container: récupérer les paquets NPM

Commande à exécuter obligatoirement avant toute autre pour récupérer les dépendances NPM du projet (dossier node_modules) en local.

Pour exécuter npm install à l’intérieur de mon container (et ainsi récupérer les dépendances node propres au projet Foundation en local sur ma machine, à la racine du dossier home/intlangf/docker/fzt/ où se trouve le fichier package.json), j’exécute la commande docker run --rm -v ~/docker/knacss:/home/app/ fzt npm install.

Exécuter une commande à l’intérieur du container: yarn start

Les sources dans Foundation se compilent via la commande yarn start qu’on exécute ainsi: docker run --rm -v ~/docker/knacss:/home/app/ fzt.

Ici on ne précise pas de commande à la suite du nom de l’image Docker, car la commande par défaut dans le fichier Dockerfile est CMD ["yarn", "start"].

Résultat: un dossier dist/ est généré en local avec les sources CSS, JS, etc, compilées via notre image Docker!


Avec KNACSS

Création de la Dockerfile

Dans home/intlangf/docker/ je fais un git clone https://github.com/alsacreations/KNACSS.git knacss (pour récupérer les sources du framework CSS Knacss).

Ensuite, cd knacss pour entrer dans le dossier créé par Git. Puis touch Dockerfile et vim Dockerfile pour créer et éditer un fichier Dockerfile dans lequel je place le code ci-dessous:

Builder le container

Pour builder le container (que je vais appeler « test »), j’exécute la commande: docker build -t test .

Exécuter une commande à l’intérieur du container

Pour exécuter npm install à l’intérieur de mon container (et ainsi récupérer les dépendances node propres au projet Knacss en local sur ma machine, à la racine du dossier home/intlangf/docker/knacss/ où se trouve le fichier package.json), j’exécute la commande docker run --rm -v ~/docker/knacss:/home/app/ test npm install.


Expériences plus anciennes

Avec une Dockerfile

Container with ready-to-run gulp-tasks sur hub.docker.com.

  1. copy the contents of the example directory to your project.
  2. change the gulpfile.js to meet your requirements (sass or less, copy included?)
  3. change the gulp_config.js to meet your requirements

4. make the gulp-File executable

Well you can make it by doing as chmod +x filename.sh so it will execute when you call it will ./filename.sh.

5. run ./gulp build:dev or ./gulp watch

see gulp running for you, without having to worry with nodejs, module dependencies, complex tasks configuration

Avec Docker Compose

Bonus:

How To Remove Docker Images, Containers, and Volumes

Remove all images and containers


[Docker] Mettre en place un container workflow de développement Front-End incluant NodeJS, NPM, Bower, Gulp, etc …

Note: déprécié au profit de [Docker][NodeJS] Utiliser Docker pour créer un environnement de développement NodeJS.

Docker for Gulp Build Tasks et version PDF pour la postérité. Cet article m’a permis de mettre en place un Docker pour compiler mes sources Front-End via NPM (workflow utilisant Bower et Gulp). Et ça marche!!!


Ressources en ligne

Tutoriels

Repositories

  • Le projet docker-npm de nkenney sous Git. Un node, npm, yarn, bower, grunt and gulp runner.