Utiliser un minifier qui inclut et minifie les fichiers via ```@import```

[eQRoeil]

Suite à notre discussion sur twitter j'ouvre cette issue pour discussion ( vu l'heure tardive j'ai choisi le français ;) ).

L'intérêt de @import pour moi est d'avoir une bibliothèque de petits bouts de css qui évolue au cours du temps. Pour un projet je choisis d'inclure ou pas ces petits bouts en fonction des besoins. Il est plus simple pour moi d'utiliser @import dans un fichier spécifique au projet plutôt que d'éditer un fichier de config ou allonger ma saisie dans la console...

Je ne considère pas que ce soit le bon (si ça existe...) workflow mais cette option est par défaut avec grunt (grunt-contrib-cssmin) qui utilise https://github.com/GoalSmashers/clean-css et j'ai été surpris de voir le @import en sortie, d'autres pourraient avoir la même surprise (?)

clean-css permet de désactiver cette option si nécessaire, mais vouloir conserver un @import en sortie... je vois pas bien l'intérêt, c'est plutôt à éviter pour les perfs non ? ;)

Je continue les tests ;)

[iamvdo]

Même si je suis plutôt contre le détournement de @import au départ, je pense finalement que ça peut être une bonne chose en terme d'optimisation.

Reste à savoir si c'est au minifier de jouer ce role ou à un autre postprocesseur, une sorte d'optimiseur, genre CSSO ?

Dans le premier cas, il faudrait faire une PR sur CSSWring, dans le second cas il faudrait créer un postprocesseur unique, comme c'est la cas pour les pseudoElements.

[raphaelgoetter]

J'ai un avis assez ouvert sur la question.

Tout d'abord, arrêtez-moi si je me trompe mais il y a déjà une concaténation de fichiers CSS actuellement avec Pleeease : si je dispose d'un fichier 00-config.css et d'un fichier 01-styles.css, alors le résultat app.min.css sera la concaténation minifiée des deux fichiers en input. Sans avoir besoin de @import

En tout cas, avec un pleeease watch ou un pleeease compile

Si ce n'est pas le cas, ce serait bien que ça le soit ;)

Si c'est déjà le cas, quel serait le vrai intérêt d'un pseudo @import ? Celui de pouvoir définir l'ordre de l'import des fichiers ? Certes.

Quoi qu'il en soit, s'il s'agit d'une fonction supplémentaire à apporter à Pleeease, je la vois plutôt comme un truc autonome et indépendant, mais pas vraiment à classer dans les "fallbacks". Tout "simplement" en un "concat": true ou un "import": true

Pour info, Stylecow utilise "import" et procède ainsi : http://oscarotero.github.io/stylecow-node/#plugin-import

EDIT : il y a plein de bonnes petites choses à récupérer de Stylecow ;)

[iamvdo]

Ta première remarque est également celle que j'ai faite à Pascal (et à d'autres) sur Twitter. En effet, Pleeease permet déjà la concaténation de fichier et l'ordre peut être gérer facilement depuis le fichier de configuration .pleeeaserc de cette manière:

{
   "input": ["00-config.css","01-styles.css"]
}

Pour ensuite lancer la commande sans paramètres:

pleeease watch

Je comprends aussi l'utilisation de @import pour inclure ses morceaux de codes réutilisables. Par contre, il ne faut pas oublier que @import est une règle normalement interprétée par le navigateur. Détourner son rôle n'est pas forcément le but de l'outil.

Par contre, si l'on se place d'un point de vue optimisation, il peut être intéressant d'empêcher une feuille de style d'être servie au navigateur avec ces @import, et donc la concaténation prend tout sons sens.

Ce que je vois pour le moment, c'est quelque chose de ce style:

{
   "fallbacks": {
      "variables": true,
      "rem": true
   }
   "optimizers": {
      "import": true,
      "mqpacker": true
   }
}

Ou fallbacks contient les postprocesseurs dédiés aux fallbacks (tiens, tiens), et une partie optimizers qui inclue import, le "packageur" de media queries, et d'autres dans le futur. Le minifieur pourrait aussi se trouver là. Et d'ailleurs Autoprefixer pourrait se trouver dans les fallbacks...

Je n'ai pas encore regardé du coté du code mais Stylecow parle de chemins relatifs uniquement, ce qui limite déjà l'utilisation de @import. Je n'aime pas trop détourner une fonctionnalité pour au final n'offrir qu'une partie du support de base. C'est d'ailleurs le même problème pour calc().

[eQRoeil]

Salut Raphaël, comme je l'ai dit c'est la suprise (que ce ne soit pas par défaut) qui m'a fait poser la question...

J'utilise @import car cela me permet d'inclure des fichiers sans toucher au fichier de config et sans avoir tous les fichiers d'un dossier inclus dans mon fichier de travail. Par exemple, j'inclus si besoin table layout (.row et .col dans knacss) Si j'ai deux fichiers pour les forms (avec des variantes de styles) j'inclus l'un ou l'autre en fonction du projet. Ces fichiers sont des ressources que je peux utiliser dans plusieurs projets (depuis une ressource, un dossier unique)

Autre exemple, je travaille sur un composant particulier avec différentes pistes. Avec 2 @import je peux switcher rapidement entre les deux pistes facilement et rapidement sans quitter mon fichier css (surtout sans toucher à la config ni les dossiers...)

L'intérêt pour moi est lié à mes habitudes... quand je teste un outil, c'est pour voir comment il (peut) s'intègre(r) à mon workflow, je ne le fais pas avec l'intention d'adapter mon forkflow à l'outil...

Pour le "comment" ça devrait être intégré (si ça l'est), c'est un peu obscur pour moi, j'ai la vision "utilisateur" de l'outil. Si c'est une option non activée par défaut je l'activerai dans la config sans me poser la question de qui fait quoi (clean-css, CSSO, CSSWring...) ;)

Cette fonctionnalité est activée par défaut dans d'autres outils (y compris stylecow) et cela me semble plutôt logique, je me pose la question dans l'autre sens : pourquoi vouloir conserver un @import en sortie?

Pour stylecow, ce qui me semble intéressant (en plus des corrections ie) c'est que la root font-size utilisée dans les calculs du fallback rem soit dans le css (sur :root ou html) plutôt que dans le fichier de config, ce qui me semble nécessaire pour pixrem (toujours pour la même raison... pouvoir modifier/tester depuis la css...)

[iamvdo]

c'est pour voir comment il (peut) s'intègre(r) à mon workflow, je ne le fais pas avec l'intention d'adapter mon workflow à l'outil...

Ça c'est bien entendu complètement vrai! Mais si tu y réfléchis, tu as forcément créer ton workflow actuel en te basant sur un outil (qui détourne l'utilisation des @import). C'est juste que tu ne peux plus t'en passer maintenant. :P

Quoiqu'il en soit, je vais commencer à regarder comment inclure cette fonctionnalité! Parmi les limitations que je vois:

• limité aux chemins relatifs (comme Stylecow, rework-import,etc.)
• pas de concaténation si utilisation de médias, type @import url("foo.css") screen and (min-width: 60em)

Vous en voyez d'autres?

[raphaelgoetter]

Pour stylecow, ce qui me semble intéressant (en plus des corrections ie) c'est que la root font-size utilisée dans les calculs du fallback rem soit dans le css (sur :root ou html) plutôt que dans le fichier de config

J'avoue que je suis fan aussi !

Vous en voyez d'autres?

Là tout de suite non, mais ce serait déjà pas mal d'en arriver là :)

[iamvdo]

Hello, La version 0.3 est dans les starting-blocks avec le support des @imports! J'en ai profité également pour refactoriser les options comme je l'avais évoqué.

Du coup, si vous voulez voir, regardez du coté de la branche issue1 (README). Si vous voulez tester, faites un git clone du projet. Puis dans le dossier test, il y a déjà quelques fichiers et une config par défaut pour faire joujou. Vous pouvez lancer pleeease depuis test de cette façon:

node ../bin/pleeease compile

[raphaelgoetter]

Salut Vincent,

Je t'avoue qu'étant peu fan de CLI et de node dès que ça devient un peu complexe, je passe la main.

Je testerai quand ce sera utilisable par un noob comme moi ;)

[eQRoeil]

Hello, comme Raphael, pas très confiant... J'ai quand même testé ;) le git clone https://github.com/iamvdo/pleeease.git a fonctionné En revanche dans test node ../bin/pleeease compile n'a pas fonctionné

Error: Cannot find module 'commander'

J'ai tenté un please compile mais le résultat ne tient pas compte de @import (ce qui est logique il me semble, cela utilise le code de la branche principale...)

Bref, avec des testeurs comme nous, t'es pas aidé (faudrait nous polyfiller)

[iamvdo]

ha ha ;) Je vais tenter de vous polyfiller (si jamais vous êtes encore motivés)

Donc, après le git clone, il faut switcher de branche. Pour cela, il faut créer une nouvelle branche locale (issue1) en se déplaçant dessus

git checkout -b issue1

Puis, il faut récupérer le code de la branche distante (issue1) et la merger dans cette branche locale:

git pull origin issue1

Ensuite, il faut installer les modules, donc:

npm install

Enfin, se déplacer dans test/ et lancer la commande:

node ../bin/pleeease compile

Quoiqu'il en soit, j'ai déjà fait pas mal de tests et pas trouvé de nouveaux bugs, donc je devrais mettre à jour cette semaine en 0.3. :)

A+

[iamvdo]

Updated to v0.3.0