[Grunt] Configuration gruntfile.js et package.json

**Amnael** · 03/07/2018, 15h06

Bonjour,

je n'ai pas trouvé de topic dédié à Grunt, j'espère donc ne pas m'être trompé d'endroit.

La problématique est la suivante.

Je possède deux sites (disons site_1 et site_2); chacun d'entre eux utilise Grunt et possèdent donc leurs propres Gruntfile.js et package.json.
Si on s'arrêtait là ce serait ok, mais le problème est du coup la duplication du répertoire nodes_modules. Cela devient assez vite lourd.
L'idée étant donc de générer un même nodes_modules / package.json / Gruntfile.js pour l'ensemble des deux sites (respectivement N sites).

Mais quelques problèmes se posent de mon point de vue:

- 1er problème, site_1 et site_2 génèrent les même devDependencies (prenons uglify par exemple). Toutefois, la version n'est pas forcément la même entre les deux.
Par conséquent, ma question est: Est-ce que l'utilisation de versions plus récentes pour certains modules peut engendrer des problèmes ? Auquel cas, quels sont-ils ? Ou bien un upgrade de la version passera systématiquement bien ?

- 2ème problème: Si la partie devDependencies peut être commune, ce n'est pas le cas pour les champs name, version, description,main et scripts qui auront tendance à être plutôt spécifique à chaque site. Ce point-là vous paraît il bloquant ? Pour le moment je ne vois pas comment faire ce pont-là.

Pour résumer: Est-il possible de fusionner ces deux fichiers package.json en un seul:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "name": "site_test_1",
  "version": "1.0.0",
  "description": "description site 1",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "grunt": "^1.0.3",
    "grunt-contrib-clean": "^1.1.0",
    "grunt-contrib-cssmin": "^2.2.1",
    "grunt-contrib-sass": "^1.0.0",
    "grunt-contrib-uglify": "^3.3.0",
    "grunt-contrib-watch": "^1.1.0",
    "grunt-svgmin": "^5.0.0",
    "load-grunt-tasks": "^4.0.0"
  }
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "name": "site_test_2",
  "version": "1.0.0",
  "description": "description site 2",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "grunt": "^1.0.3",
    "grunt-contrib-clean": "^1.1.0",
    "grunt-contrib-cssmin": "^2.2.1",
    "grunt-contrib-sass": "^1.0.0",
    "grunt-contrib-uglify": "^3.3.0",
    "grunt-contrib-watch": "^1.1.0",
    "grunt-svgmin": "^5.0.0",
    "load-grunt-tasks": "^4.0.0"
  }
}

Troisième problème: Au niveau du Gruntfile.js.
Voici à quoi ressemblerait le fichier de chacun des deux sites

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
module.exports = function(grunt) {
 
  grunt.loadNpmTasks('grunt-contrib-uglify');
 
  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    //Lancer la commande "grunt uglify" pour minifier les fichiers js des répertoires /assets et /lib
    uglify:{
      options: {
        preserveComments: false
      },
      frontend: {
        files: [{
          expand: true,
          cwd: 'assets/js/frontend/',
          src: [ '*.js' ],
          dest: 'assets/js/frontend/',
          ext: '.min.js'
        }]
      }
    }
  });
  grunt.registerTask('default', ['uglify']);
};

Maintenant si je rentre dans la configuration ou je veux n'avoir plus qu'un Gruntfile.js pour tous les sites, je dois d'une façon ou d'une autre exprimer les nouveaux chemins.
La solution évidente qui m’apparaît est la suivante ou il suffirait de lister pour chaque site les règles

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
module.exports = function(grunt) {
 
  grunt.loadNpmTasks('grunt-contrib-uglify');
 
  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    //Lancer la commande "grunt uglify" pour minifier les fichiers js des répertoires /assets et /lib
    uglify:{
      options: {
        preserveComments: false
      },
      frontend_site_1: {
        files: [{
          expand: true,
          cwd: 'site_1/assets/js/frontend/',
          src: [ '*.js' ],
          dest: 'site_1/assets/js/frontend/',
          ext: '.min.js'
        }]
      },
      frontend_site_2: {
        files: [{
          expand: true,
          cwd: 'site_2/assets/js/frontend/',
          src: [ '*.js' ],
          dest: 'site_2/assets/js/frontend/',
          ext: '.min.js'
        }]
      }
    }
  });
  grunt.registerTask('default', ['uglify']);
};

Le problème, c'est que là aussi, ça va devenir très rapidement indigeste et difficile à maintenant comme fichier.

Je me demande donc s'il est possible de générer dynamiquement le contenu de ce fichier en fonction d'un tableau contenant une liste de site qui construirait le json que l'on passerait par la suite en argument au grunt.initConfig.
J'ai quelque doute car j'ai peur que si je construit le paramètre de initConfig comme un string alors les fonctions comme celle-ci pourrait se retrouver non interprété.

Code :

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

pkg: grunt.file.readJSON('package.json'),

Je suis preneur de tout avis sur ces questions. Pour le moment c'est plus de la réflexion qu'autre chose.

Merci d'avance.

**Marco46** · 03/07/2018, 16h44

Ce n'est pas parce que à un instant T tu as 2 projets qui ont des dépendances de développement quasi identiques que ça sera le cas dans le futur. Peut être que le projet site_2 aura du budget pour évoluer pendant 2 ans auquel cas tu vas le faire passer de grunt à des choses plus récentes comme Webpack ou rollup. Et ton site_1 restera sur grunt parce qu'il n'aura du budget que pour quelques hotfix.

C'est le cycle de vie du projet qui drive ça. La partie devDep n'est donc pas commune, elle semble identique à un instant T parce que tu as développé les 2 projets en parallèle mais c'est un trompe l'oeil. Si tu as 2 projets avec 2 cycles de vie différents tu es obligé d'avoir des devDep différentes et clairement séparées sinon tu vas au devant de graves problèmes de maintenance.

**Amnael** · 03/07/2018, 16h58

Plutôt d'accord avec toi, mais c'est une exigence de regrouper tous les projets tournant avec Grunt qui ne vient pas de moi, donc obligé de le pencher dessus, au moins pour voir la faisabilité du truc.
Donc si éventuellement un projet passait sur autre chose que Grunt, il sera simplement retiré de cet emplacement pour le mettre dans un nouvel environnement supportant le nouveau type de dépendance.
C'est la raison pour laquelle je dis que seule la version peut éventuellement varier dans le sens ou...c'est soit la version varie soit le projet est envoyé ailleurs.

Mais dans le fond on peut partir sur l'hypothèse que le DevDep est bien différent (la version en elle-même étant une différence). Je dois donc cherche un moyen de gérer ses différences à la construction du json...si cela est possible, ce dont je ne suis même pas certain.

EDIT:

J'aimerais aussi savoir s'il y a un moyen de connaître dans le gruntfile.js dans quel répertoire la commande grunt a été lancé (qui n'est pas forcément l'emplacement du fichier gruntfile.js puisque la commande est valable dans chaque sous dossiers).

**Marco46** · 03/07/2018, 19h44

Envoyé par Amnael

Plutôt d'accord avec toi, mais c'est une exigence de regrouper tous les projets tournant avec Grunt qui ne vient pas de moi, donc obligé de le pencher dessus, au moins pour voir la faisabilité du truc.

De qui vient-elle ?

Envoyé par Amnael

Donc si éventuellement un projet passait sur autre chose que Grunt, il sera simplement retiré de cet emplacement pour le mettre dans un nouvel environnement supportant le nouveau type de dépendance.

C'est la raison pour laquelle je dis que seule la version peut éventuellement varier dans le sens ou...c'est soit la version varie soit le projet est envoyé ailleurs.

De quel emplacement ?

Le "container" de ton projet c'est le package.json. C'est lui qui représente ton projet. Un projet a donc une liste de dependencies et une liste de devDependencies.

Le tout est versionné par git (si tu utilises svn il faut migrer asap).

Après tu peux considérer que ton projet est composé de plusieurs packages, et tu auras donc un repo git contenant plusieurs répertoire à la racine qui seront tes packages avec chacun un package.json.

Il existe un outil pour gérer ça, ça s'appelle lerna.

Ça va te donner une structure de ce type :

Code :

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

1
2
3
4
5
6
7
8
 
my-lerna-repo/
  package.json
  packages/
    package-1/
      package.json
    package-2/
      package.json

Il y a une section de la doc qui explique comment mutualiser des devDependencies dans le package.json situé à la racine.

Mais c'est un gros travail que d'apprivoiser cet outil c'est utile pour les très gros projets avec beaucoup de packages, genre Angular.

La question est surtout de savoir si l'investissement est utile dans ton contexte.

Envoyé par Amnael

Mais dans le fond on peut partir sur l'hypothèse que le DevDep est bien différent (la version en elle-même étant une différence). Je dois donc cherche un moyen de gérer ses différences à la construction du json...si cela est possible, ce dont je ne suis même pas certain.

De quel json parles-tu ? Le package.json ? Les dépendances ne doivent surtout pas être dynamiques, elles sont fixées par ton package-lock.json ! La gestion des dépendances doit être déterministe, si tu checkout un tag x.y.z tu dois être certain de retrouver chaque dépendance (y compris le subtree) strictement dans les mêmes versions partout. En d'autres termes si un dev checkout un tag donné 3 mois après que ce tag a été créé, il doit obtenir le même dependency tree qu'au moment où ce tag a été créé sinon c'est un bordel immonde.

Envoyé par Amnael

EDIT:

J'aimerais aussi savoir s'il y a un moyen de connaître dans le gruntfile.js dans quel répertoire la commande grunt a été lancé (qui n'est pas forcément l'emplacement du fichier gruntfile.js puisque la commande est valable dans chaque sous dossiers).

Je ne sais pas mais clairement grunt est un vieil outil qui n'a pas été pensé pour ça. Un investissement plus utile que de mutualiser vos dépendances de développement serait peut être déjà de commencer par les mettre à jour.

**Amnael** · 04/07/2018, 09h57

Après tu peux considérer que ton projet est composé de plusieurs packages, et tu auras donc un repo git contenant plusieurs répertoire

Ce sont bel et bien des projets différents avec un repository git chacun. De ce coté là, ça ne changera pas.

Mais ça ne veut pas dire que l'on ne devrait pas pouvoir externaliser les tâches de Grunt.
Il ne s'agit pas tant de dire, on va mettre toutes les mêmes dépendances pour tous les projets, mais plutôt de dire

Si je suis sur le projet X j'utilise les dépendances Y .... si je suis sur le projet N j'utilise les dépendances Z etc etc.

Dans le Gruntfile.js je pense que cette distinction peut se faire puisque l'on pourra faire des loadNpmTasks ou spécifier le comportement même des tâches en fonction du projet réellement. Mon problème actuellement ce serait plus de trouver comment spécifier ce nom de projet. Si j'ai un répertoire Mes Sites contenant site 1 et site 2.
L'idéal serait de pouvoir faire tourner des commandes du style

grunt uglify site_1
grunt uglify site_2

depuis le répertoire mes sites ou tout de moins grunt uglify depuis site_1 en sachant que l'on serait dans site_1. D'où mon interrogation pour savoir si l'on peut récupérer le path d'où grunt est appelé.

Tout cela est je pense possible; en revanche c'est ce point là qui risque de bloquer.

La gestion des dépendances doit être déterministe

Elles le seraient toujours, mais leur déterminisme serait conditionné par leur nom de projet (et oui je parle bien du package.json).
Mais, peut-être le terme que tu voulais employer n'est pas déterministe, mais plutôt statique ? Auquel cas ce point devient bloquant.

**Marco46** · 04/07/2018, 10h15

Envoyé par Amnael

Mais ça ne veut pas dire que l'on ne devrait pas pouvoir externaliser les tâches de Grunt.

C'est pas les tâches grunt que vous voulez externaliser mais leur config (le gruntfile). Les taches grunt s'externalisent très bien au moyen des plugins.

Envoyé par Amnael

Il ne s'agit pas tant de dire, on va mettre toutes les mêmes dépendances pour tous les projets, mais plutôt de dire

Si je suis sur le projet X j'utilise les dépendances Y .... si je suis sur le projet N j'utilise les dépendances Z etc etc.

Oui j'ai compris. C'est horriblement compliqué pour rien ne faites pas ça.

Ce que vous voulez faire c'est avoir un package contenant un gruntfile commun qui conditionne sa propre config en fonction des dépendances de packages externes. C'est vraiment pas la bonne méthode.

Prenez 3 jours pour passer à Webpack vous aurez un résultat similaire avec un truc propre. Les outils comme Webpack ou Rollup ont été écrits justement pour plus avoir à se taper tout ce boilerplate comme avec gulp où au final on passe un temps de fou à développer et debuguer ces scripts. Avec Webpack ou Rollup tu n'auras plus que de la config à effectué (de la vraie config) et les services classiques te seront rendus.

Tu n'as pas répondu sur ma question de qui te demande de réfléchir à ça, simple et malsaine curiosité de ma part

**Amnael** · 04/07/2018, 10h43

Tu n'as pas répondu sur ma question de qui te demande de réfléchir à ça, simple et malsaine curiosité de ma part

La personne maléfique, qui cachée dans l'ombre fait les plannings

Je vais check Webpack aussi du coup, mais j'ai peur que faire la migration de multiples sites de grunt à webpack soit assez fastidieux^^
C'est bien d'avoir ça comme proposition par contre, mais ça n'empêche que je vais continuer un peu à explorer le problème, car justement s'ils voient à quel point c'est une galère ça devrait aider à migrer^^

Merci.

**Marco46** · 04/07/2018, 10h57

Envoyé par Amnael

La personne maléfique, qui cachée dans l'ombre fait les plannings

Le chef de projet ? LOL

C'est le genre de CdP qui a été junior pendant 2 ans avant de devenir CdP et qui se permet de donner des orientations techniques ?

La demande initiale était suspecte du coup je me doutais que c'était un truc du genre ...

**Amnael** · 04/07/2018, 11h38

C'est le genre de CdP qui a été junior pendant 2 ans avant de devenir CdP et qui se permet de donner des orientations techniques ?

Non du tout, après c'est juste de la recherche, c'est pas parce que j'ai une orientation de base que je ne peux pas proposer autre chose à coté

Je reviens à mes moutons:

En bidouillant un peu pour continuer à creuser, j'ai fais un truc comme ça

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
  grunt.registerTask('hightLevelTask', 'Ma tache générale pour tous les sites', function(tache,site) {
    if (arguments.length === 0) {
      grunt.log.writeln(this.name + ", La tache et le nom du site doit être passé en argument");
    } else {
 
      grunt.initConfig({
        pkg: grunt.file.readJSON('package.json'),
 
        uglify:{
          options: {
            preserveComments: false
          },
          frontend: {
            files: [{
              expand: true,
              cwd: site+'assets/js/frontend/',
              src: [ '*.js' ],
              dest: site+'assets/js/frontend/',
              ext: '.min.js'
            }]
          },
        }
      });
    }
});

Je crée une nouvelle tache ayant pour argument la commande que je voudrais lancer ainsi que le site sur lequel elle sera lancé.

De cette façon je peux faire mon initConfig "dynamique" en fonction du site.

Par contre, cela ne fait donc qu'enregistrer la tache, j'aimerais après le initConfig pouvoir "lancer" la tache sans passer par la ligne de commande et du coup si je fais

hightLevelTask:uglify:site_1 je voudrais que cela soit équivalent à lancer le uglify qui a été stocké avec initConfig.

EDIT: Bon et bien, c'est ptetre pas très propre mais ça fonctionne

La tache pouvant être lancée par grunt.task.run(tache);

grunt hightLevelTask:uglify:site_test_1
Running "hightLevelTask:uglify:site_test_1" (hightLevelTask) task

Running "uglify:frontend" (uglify) task
>> 1 file created 302 B → 195 B

Done.

[Grunt] Configuration gruntfile.js et package.json

Outils

Discussions similaires

Partager

Partager