Double Class Compilation SASS

Bonjour,

Voila j'ai récemment lu un article intéressant sur le guide de style SASS http://sass-guidelin.es/fr/

Ma question concerne l'organisation de la structure de fichiers :

Pour les library extérieur ou plugin qui ne nous appartiennent pas, j'ai lu qu'il fallait les placer dans un dossier /vendor. Jusqu'ici tout va bien. Lorsque qu'on souhaite apporter des modifications, par exemple a des fichier de bootstrap, il faut créer alors un dossier vendor-extension.

Le problème c'est que dès lors qu'on reprends une class pour l'éditer, celle-ci est doublé lors de la compilation, est-ce normal ?

J'aimerais également connaitre votre façon de faire, vous éditez directement dans le fichier source ou alors vous créez un fichier avec les modifications et la class concernées qui viendra écraser la source.

Je trouve ça "propre" mais surtout long, à perdre beaucoup de temps ...

Merci !

Qu'entends tu pas doublé ?

Il ne vaut mieux pas éditer les fichiers sources créés par d'autres car cela crée de gros problèmes de maintenance. 1. ça change le comportement du framework ce qui est mal venu. 2. Si demain quelqu'un veux mettre à jour bootstrap pour x ou y raison, il devra reprendre toutes les modifs une a une ce qui reviendra à refaire le boulot.

Donc toujours faire ses modifs à part.

Bonjour,

cela fait quelques années que je cherche ce genre d'outil que ce soit :
- du côté des outils de versionnement (faire des modifications sur du code qui sera mis à jour un jour à l'autre et être capable de "rejouer" ses modifications : bon c'est ce que fait un .patch en fait mais il faudrait que ce soit super intelligemment fait, pas selon le n° de ligne... Bref, garantie de casser son code assez rapidement )
- avec des outils spécialisés. Pour des CSS, c'est forcément possible de le faire avec un plugin PostCSS. J'ai regardé sur http://postcss.parts et ce qui s'en rapproche le plus serait https://github.com/AoDev/css-byebye

a écrit :
CSS Byebye is a node module that lets you explicitly remove the CSS rules that you don't want.

Ça implique de (tout lister à la main et de) dupliquer dans le fichier vendor-extension très exactement la règle vendor qui va être supprimée par le plugin PostCSS et donc d'y intégrer les modifs voulues ET celles qu'on a pas l'intention de modifier... (et de surveiller à chaque mise à jour)
L'idéal serait un plugin qui prenne les instructions du fichier vendor-extension, cherche dans vendor le sélecteur identique et y ajoute à la fin du bloc de règle l'instruction de vendor-extension (ou remplace la valeur de la propriété correspondante mais c'est pas indispensable car un minifieur virera l'instruction en trop ^^).
Une base de travail pourrait être postcss-discard-duplicates plus que postcss-merge-rules
Modifié par Felipe (14 Apr 2016 - 10:59)

@bzh : Oui je suis d'accord avec toi.

@Felipe : Très intéressant pour les plugins en lien, il est vrai que je commence seulement à utiliser cette méthodologie. Donc il faut vraiment travailler POSTCSS.

Comment travaillez vous de votre côté ? Est-ce vous optimisez en pre-prod ou directement en production ?

Autoprefixer est une raison suffisante pour commencer à utiliser npm/gulp/grunt/autre (c'est un plugin PostCSS mais c'est transparent)

PostCSS a l'immense avantage de parser à la perfection les CSS, y compris les hacks bizarroïdes de http://browserhacks.com : du travail de qualité et robuste. Et si on veut écrire soi-même des plugins (a priori aucun besoin hein, l'écosystème est bien actif !), même moi j'ai réussi à me servir de leur API : elle est simple.

Sangohan62 a écrit :
Comment travaillez vous de votre côté ? Est-ce vous optimisez en pre-prod ou directement en production ?

Ça je n'optimise pas. On n'a pas de client intéressé - dans mes souvenirs - par des optimisations aussi poussées (UnCSS, Critical) quoique vu qu'on utilise KNACSS en commentant les bouts qu'on ne veut pas (perso les grilles) et pas un mastodonte comme Bootstrap ou Foundation, on a peu de règles inutilisées
Par contre les optimisations qui ont un effet important, ça oui c'est dans notre méthodologie :
- optimisation des images
- concaténation et minification des CSS, du JS
- optimisation des SVG
- etc
Et la base est même sur GitHub : bretzel

Note : il est peu courant qu'on ait accès à la prod et même à la pré-prod mais c'est spécifique à l'agence Alsacréations ; on vient nous voir pour des refontes ergo, UX, graphiques, de l'intégration HTML/CSS, un thème pour site WordPress fait à la main (pas un template qui ne correspond pas aux besoins...) et de l'accessibilité, de la webperf, des audits en tout genre bien plus que pour des projets de A à Z où on héberge et maintient pendant des années (mais ça arrive aussi).
La prod va plus souvent être faite par le développeur ou le chef de projet qui est notre client ou l'un de ses prestas et là on lui donne toutes nos sources avec documentation voire formation.
La plupart des autres membres du Forum doivent eux avoir pour quotidien la gestion en parallèle de dév/pré-prod et prod

Il est vrai que la sur-optimisation a un cout, et que la plupart de nos clients ne s'en pré-occupe pas du tout...

Bretzel semble être un excellent outil qui regroupe vraiment toutes les fonctionnalités. Encore mieux vu le passage à SASS...

Merci pour tous ces conseils, il n'y a plus qu'à optimiser tout ça !

Sangohan62 a écrit :
Il est vrai que la sur-optimisation a un cout..
.

Ou pas. Tout dépend de la manière de travailler. Les task runners font très bien le boulot. Le premier projet prend du temps pour être configuré, il y a donc un investissement de départ. Les suivants seront de simples copier-coller de cette config, avec éventuellement un changement des noms de repertoires.

Olivier C a écrit :

Ou pas. Tout dépend de la manière de travailler. Les task runners font très bien le boulot. Le premier projet prend du temps pour être configuré, il y a donc un investissement de départ. Les suivants seront de simples copier-coller de cette config, avec éventuellement un changement des noms de repertoires.

J'abonderai dans le sens d'Olivier.
Il est évident qu'une optimisation en amont est chronophage et présente donc un surcoût.
Par contre, si les processus / outils on été bien pensés / réalisés, leur utilisation ultérieure est un retour sur investissement gagnant, tant en terme de temps que de fiabilité.
Le problème reste in fine toujours le même, soit produire sans fignoler, soit construire, éventuellement en parallèle avec l'activité quotidienne, un système plus performant.
Dans ma boîte c'est clairement l'orientation vers le vite fait jetable qui prévaut en ce moment ce qui, sur le long terme est une énorme co*****, ne serait ce que parce qu'on recourt un max à des prestations externes, entraînant une déperdition flagrante des connaissances internes.
Certains esprits un peu plus clairvoyants que les autres tirent la sonnette d'alarme, mais avec un encadrement qui n'est que de passage et doit justifier avoir réduit les coûts s'il veut toucher ses bonus, que les autres aient à gérer le m****r dans quelques années est le dernier de leurs soucis.
Pour des gens de ma génération ayant baigné dans des règles organisationnelles nettement plus rigoureuses, ce n'est pas l'envie qui manque de filer quelques coups de pied au c**.
M'enfin, bientôt la retraite...

sepecat a écrit :
... M'enfin, bientôt la retraite...

D'où l'idée du "générateur" comme passe-temps ?

Olivier C a écrit :
D'où l'idée du "générateur" comme passe-temps ?

Tu ne crois pas si bien dire
En fait, l'idée a germé en constatant que si je me suis (vraiment) éclaté au boulot par le passé , ce n'était plus vraiment le cas, alors même qu'à titre personnel et l'expérience aidant je suis de plus en plus porté sur l'innovation et l'approfondissement des connaissances, notamment web (pas encore sclérosé le papy).
L'entreprise n'offrant plus un terrain de jeu suffisant (pour faire court, tu vas au-delà des objectifs et on te réduit le bonus ), il m'a semblé qu'il était temps de capitaliser sur l'acquis et développer encore plus les compétences, histoire de valoriser tout ceci (ou pas... ) la retraite venue.
Même si je n'en fais pas alors une activité en tant qu'auto-entrepreneur (je verai à ce moment là si l'aventure est pertinente), j'ai tout de même en tête quelques idées de sites web que je voudrais bien réaliser le moment venu.
Pour l'instant en tout cas rien ne m'indique que le générateur ne puisse être viable et le développement se poursuit donc, avec un long chemin restant à parcourir (mais c'est passionnant, tant le web nous fait toucher à des techniques fort différentes).