Less.js: propriétés dupliquées lors de l'@import plusieurs fois (import @ imbriqué)

Je suppose que le problème est que le fichier est importé deux fois, c'est le comportement correct pour les mixins.

Pensez-vous qu'il devrait importer le fichier deux fois ? Sinon, il doit également prendre en compte les URL relatives. Par exemple

// in main.less
<strong i="6">@import</strong>: imports/import1.less;
<strong i="7">@import</strong>: imports/import2.less;

// in imports/import1.less
<strong i="8">@import</strong>: import2.less; // don't import this
<strong i="9">@import</strong>: imports/import2.less; // do import this

hmmm, je me demande s'il existe un moyen plus simple de vérifier si un fichier est égal à un autre fichier. Peut-être quelque chose dans les en-têtes.

La taille du fichier est un indicateur bon marché et est probablement unique dans un ensemble donné de fichiers source. Cependant il est _possible_ d'avoir 2 fichiers de même taille.

De même avec la date modifiée.

Si le serveur définit l'en-tête ETag, vous pouvez/devriez l'utiliser.

Nous utilisons le hachage MD5 du contenu du fichier comme clé lors de la mise en cache, mais je pense personnellement que c'est exagéré.

hmmm, oui le problème est que javascript n'a pas de MD5 natif, ou je l'utiliserais ..
ETag serait idéal, mais certains serveurs ne le définissent pas. Je vais devoir y penser.

Il semble que nous soyons d'accord pour que les fichiers ne soient pas importés deux fois. Cependant est-ce toujours vrai ? (c'est-à-dire avec l'aide de scope, l'importation dans un mixim peut être ok - cloudhead vous pouvez répondre mieux que moi sur celui-ci).

De nombreuses langues ont déjà résolu ce problème de différentes manières :

• C -> #ifndef / #define / #endif
• PHP -> include_once()

La "voie C" peut être un peu plus difficile à mettre en œuvre, mais les conditions peuvent offrir d'autres grandes possibilités.

Si le "chemin PHP" est choisi, nous devons choisir un moyen de différencier les fichiers. L'URL absolue semble un bon choix (nous l'avons soit directement, soit via document.location + URL relative) - je pense que c'est mieux que size / length / MD5 car elle ne consomme pas de requête HTTP.
Cependant, cela peut ne pas suffire : chaque URL est mappée sur un seul fichier, mais chaque fichier peut être mappé sur plusieurs URL. Dans ce cas, l'introduction d'un nouveau mot-clé @<strong i="16">@name</strong>: <unique name> peut aider.

L'algo @import_once serait alors : si l'URL absolue n'a pas déjà été importée, récupérer les fichiers et vérifier si le @ @name a déjà été importé, sinon importer le fichier.

Je suis d'accord. dans le contexte d'une seule demande, vous devriez pouvoir supposer que les ressources ne changent pas. donc les URL absolues devraient être assez bonnes.

vérifier les changements de fichier est une autre affaire.

je pense que nous devrions conserver @import import plusieurs fois car c'est ainsi que fonctionne

i comme @vicb « solution s comme php, mais au lieu de @import_once i comme quelque chose de mieux dans « commentaire » il toujours compatible avec la syntaxe originale css.

pouvons-nous ajouter quelque chose comme ceci en haut du fichier .less :
/_! require:url (./abc.less)_/

Je rencontre également ce problème. Mon projet a une hiérarchie de fichiers LESS compilés en un seul fichier .css. Il y a un fichier utilitaire MOINS qui est inclus dans plusieurs fichiers, au final, tous les mixins sont dupliqués le même nombre de fois que ce fichier utilitaire a été importé.

Un @import_once , ou peut-être @import : once url('url'); résoudrait ce problème.

Nous sommes confrontés au même problème que @NielsJanssen sur notre projet, une idée de quand ce problème sera-t-il résolu ??

Je rencontre également ce problème. Quelqu'un a trouvé une solution ?

Avoir le même problème ici. Je n'ai pas pu trouver de solution simple, j'ai juste fini par réorganiser les importations afin qu'elles ne soient pas importées deux fois.

Je suggère vraiment de vérifier Stylus si vous utilisez node.js. J'ai utilisé LESS pendant un certain temps, j'ai été frustré par son manque total de développement, je suis passé à SASS puis finalement à Stylus. Il cloue vraiment les fonctionnalités, la syntaxe est facultative (et j'utilise un juste milieu), c'est très puissant, et TJ en est un développeur vraiment réactif.

Si vous n'utilisez pas node.js, vous pouvez toujours utiliser Stylus avec ruby ​​et compiler sur votre machine. Et si vous n'aimez pas Stylus pour une raison quelconque, SASS/SCSS est également une bonne alternative et peut être fait de la même manière.

Pour faire court : MOINS n'est pas bon à long terme.

Très mauvaise attitude mec.

Il n'est pas nécessaire de poster ce bs ici. Vous auriez pu l'envoyer par courrier ou similaire. Vous ne pouvez pas avoir des normes aussi élevées que de vouloir un "développeur vraiment réactif" pour quelque chose qui est libre d'utilisation.

Absolument pas.

J'aurais adoré ce conseil lorsque j'ai trouvé LESS pour la première fois afin de ne pas perdre des semaines de mon temps à m'y habituer et à m'y convertir et à partir de celui-ci lorsque je suis finalement parti. Certes, j'aurais dû le remarquer moi-même en premier, car il y a plus de problèmes ouverts que de problèmes fermés, et la plupart d'entre eux n'ont pas reçu de réponse.

Il ne s'agit pas des normes que je peux ou ne peux pas avoir. Il s'agit d'avertir les gens lorsqu'il existe de meilleures alternatives.

Je maintiens donc mon "BS" et j'espère que les gens trouveront l'avertissement utile.

@ianstormtaylor : dire qu'un projet n'est "pas bon à long terme" est un peu hystérique.

avoir ce même problème aussi.

foo.moins

<strong i="7">@import</strong> "bar.less";
<strong i="8">@import</strong> "baz.less";

bar.moins

<strong i="12">@import</strong> "mixins.less";
.bar {
  .mixer
}

baz.moins

<strong i="16">@import</strong> "mixins.less";
.baz {
  .mixer
}

mixins.less

.mixer {
  color: 000;
  border: 2px solid #fff;
}

$ lessc foo.less
.mixer {
  color: 000;
  border: 2px solid #fff;
}
.bar {
  color: 000;
  border: 2px solid #fff;
  color: 000;
  border: 2px solid #fff;
}
.mixer {
  color: 000;
  border: 2px solid #fff;
}
.baz {
  color: 000;
  border: 2px solid #fff;
  color: 000;
  border: 2px solid #fff;
}

Je suis resté en dehors de cette discussion plus tôt, mais maintenant que je suis confronté au même problème... @wlangstroth, je ne pense pas que @ianstormtaylor soit du tout hystérique. il suffit de vérifier la liste des problèmes ouverts pour ce projet et depuis combien de temps certains d'entre eux ont été ouverts. less est un outil utile mais je pense que c'est une évaluation juste que le support est limité et cela devient très frustrant en attendant.

j'ai l'impression que @cloudhead ignore principalement tous les commentaires que je fais (peut-être que je me trompe) mais il serait préférable d'entendre "je suis occupé" ou "je ne veux pas résoudre ce problème" ou même quelque chose de plus dur plutôt que d'obtenir aucune réponse du tout.

Vous _pourriez_ simplement avoir un fichier main.less contenant toutes vos importations. Voir le bootstrap de twitter pour un exemple (le fichier principal est bootstrap.less ).

certains des moins de fichiers que j'importe (à partir d'une bibliothèque externe) sont écrits pour pouvoir être compilés de manière autonome, ils incluent donc chacun un variables.less commun et le problème que je vois se produit parce que j'importe chacun de ces moins de fichiers dans un fichier principal, puis la compilation de ce fichier applique chaque mixin autant de fois que les mixins sont inclus (une fois pour chaque fichier que j'inclus à partir de la bibliothèque externe).

vous avez raison - je _pourrais_ faire quelque chose comme vous l'avez suggéré et je _suis_ en train de faire quelque chose comme ça dans le code sur lequel j'ai un contrôle total, mais cela ne veut pas dire que tout le monde le fait comme ça.

aussi, une solution de contournement (_only_ si je n'utilisais pas une bibliothèque tierce) ne change pas qu'il s'agit d'un bogue. Je suis devenu assez familier avec la façon de contourner les problèmes avec moins, mais c'est frustrant que des bogues comme celui-ci soient ouverts depuis près de 18 mois. ( @wlangstroth je me rends compte que ce n'est pas de ta faute)

pour tous ceux qui sont intéressés, j'ai un correctif de force brute (non testé par rapport au test de @vicb mais devrait fonctionner) que j'ai collé dans un commentaire sur #431. Je vais essayer de trouver une meilleure solution si j'ai plus de temps.

avoir le même problème

J'ai également eu ce problème, mais je l'ai résolu en important mes bibliothèques mixin dans mon bootstrap.less. Je ne savais pas que les importations ultérieures y auraient accès, mais cela a du sens.

fyi #431 est une pull request qui résout ce problème

@cloudhead Seriez-vous en mesure d'appliquer un correctif pour cela. C'est probablement l'une des questions les plus anciennes qui est encore ouverte. Ce serait bien de le voir résolu.

Même problème :-(

En guise de suggestion à tous ceux qui rencontrent des problèmes avec ce problème, je vous recommande de laisser un message à Alexis sur Twitter. Alexis a déjà déclaré dans plusieurs tickets qu'il ne peut pas surveiller tous les problèmes et qu'il ne les corrige vraiment que lorsqu'il est informé de la gravité. Je considère qu'il s'agit d'un problème grave, mais je n'ai pas pu le porter à l'attention d'Alexis sur Twitter.

Peut-être que quelqu'un d'autre aura plus de chance.

Twitter : https://twitter.com/#!/cloudhead

Et déposez un lien vers ce numéro : https://github.com/cloudhead/less.js/issues/49

@Kalyse si @cloudhead ne peut pas surveiller de manière adéquate les problèmes de ce projet, c'est une raison de plus pour que tout le monde évite de l'utiliser. les gens ont suggéré qu'il devrait nommer d'autres personnes pour aider à gérer l'arriéré des problèmes, mais encore une fois, il n'y a eu aucune réponse.

pourquoi devrais-je utiliser Twitter pour attirer l'attention de quelqu'un alors qu'il peut déjà recevoir des alertes lorsque je le mentionne dans un problème ? Je pense que c'est honteux que @cloudhead ne puisse pas répondre aux problèmes qui sont ouverts depuis 2 ans - il pourrait au moins trouver quelques personnes en qui il a confiance et les faire commencer à travailler sur l'arriéré des problèmes ouverts. ils pourraient au moins fermer les doublons et aider à réduire le nombre de problèmes ouverts pour lui.

Le système de notification github est complètement inutile - je reçois environ 70 à 100 notifications par jour, je préfère donc les ignorer.

je vais me renseigner là-dessus..

Ok, j'ai ajouté une directive @import-once - c'est assez rudimentaire, car elle vérifie seulement que les chemins correspondent - mais elle devrait couvrir la plupart des cas d'utilisation.

@cloudhead Heureux que vous

Personnellement, je ne comprends pas pourquoi ce projet est même sur Github si les demandes d'extraction ne sont même pas prises en compte ou pourquoi le suivi des problèmes est même en cours d'exécution si les problèmes sont ignorés.

Les gens faciles ! Si une personne avait un projet aussi populaire, elle serait dans le même bateau. @cloudhead a fait un excellent travail et a peut-être besoin d'ajouter quelques personnes de confiance en tant qu'administrateurs. Mais les problèmes avec les pull request et les tests sont beaucoup plus utiles que les problèmes seuls. Peut-être résoudre certains problèmes pendant que vous vous détendez.

Les gens ont résolu de nombreux problèmes, il y a parfois des années. Allez voir l'une des 74 demandes de tirage en attente sans réponse. À titre d'exemple, ce problème même a de nombreuses dupes remontant à 2 ans (comme #324 #71). Voici une pull request qui aurait résolu ce problème assez simplement : https://github.com/cloudhead/less.js/pull/431Le commiter a demandé des commentaires, a rencontré le silence, puis a finalement abandonné.

@cloudhead - Alexis, c'est un trop beau projet pour le laisser tomber en ruine. Lorsque les gens voient le genre de chose mentionné ci-dessus, cela leur laisse l'impression que le projet n'est pas digne de confiance ou fiable. Et c'est inutile ! La magie de github est que vous pouvez facilement trouver des personnes qui écrivent du bon code et qui souhaitent s'engager dans le projet. Demandez à ces bonnes personnes si elles peuvent aider à modérer les problèmes et les demandes d'extraction.

Nous aimons tous votre travail. La communauté veut aider. Aidons-nous !

@jeremyricketts bon point.

Je suis d'accord avec @jeremyricketts -- dans une entreprise pour laquelle je travaille, nous avons fini par ne pas

@cloudhead il semble que la directive @import-once ne fonctionne pas, c'est mon cas de test.

// a.less
.gain-bfc() {
  overflow: hidden;
  *zoom: 1;
}

// b.less
@import-once "a.less";

// c.less
@import-once "a.less";
@import-once "b.less";

div {
  .gain-bfc();
}

après avoir compilé le c.less , le résultat attendu devrait être

div {
  overflow: hidden;
  *zoom: 1;
}

mais j'ai les propriétés dupliquées

div {
  overflow: hidden;
  *zoom: 1;
  overflow: hidden;
  *zoom: 1;
}

+1 jeremyricketts

tout le monde veut intensifier - https://twitter.com/#!/neonstalwart/status/183247994072735744

Quelqu'un avec quelques côtelettes de programmation réelles est nécessaire. Mon monde est PSD, crayon et papier, et html CSS et jQuery léger.

Quelques personnes sont nécessaires juste pour trier les problèmes et les demandes d'extraction,
élaguer les doublons, s'assurer qu'il y a des cas de test pour les bogues, etc. J'aimerais
de se porter volontaire pour aider à tout le moins, et je peux probablement aider
fermez aussi les petits bogues.
Le 23 mars 2012 13:28, "Jeremy Ricketts" <
ré[email protected]>
a écrit:

Quelqu'un avec quelques côtelettes de programmation réelles est nécessaire. Mon monde est PSD,
crayon et papier, et html CSS et jQuery léger.

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/cloudhead/less.js/issues/49#issuecomment-4667283

@cloudhead Juste au cas où vous auriez du mal à @neonstalwart d'il y a quelque temps.

Fondamentalement, les règles ne doivent jamais être ajoutées aux sélecteurs s'il existe une règle existante avec la même valeur que la propriété actuelle. Vous devez également vérifier la valeur de la propriété, car avec les arrière-plans, vous pouvez ajouter plusieurs arrière-plans différents car ils sont gérés différemment dans différents navigateurs.

Que pensez-vous de cette solution @cloudhead
Cela semble être la voie à suivre ?

Ne pas corriger cela signifie :

1) Les fichiers sont plus volumineux qu'ils ne devraient l'être.
2) Répartir votre CSS sur plusieurs fichiers et importer des lots devient indésirable car pour chaque fois que vous incluez un fichier supplémentaire qui inclut également les mixins, vous ajoutez à nouveau les valeurs de ce mixin. J'ai peut-être 80 styles de moins CSS, ce qui signifie que lorsque je fais un mélange de dégradé .background(), cela donne 80 * 6 styles supplémentaires pour chaque sélecteur. (6 pour prendre en charge tous les différents navigateurs).
3) Il ralentit également le rendu des pages. Mes tirages/actualisations par seconde diminuent considérablement en raison des styles supplémentaires.

Pensées @cloudhead ?
À votre santé.

@cloudhead Si nous faisons une pull request pour ce problème à partir du dernier commit, envisagerez-vous de fusionner ?

Voici le correctif : https://github.com/cloudhead/less.js/commit/cb789334233e377bd91a17d3118a0424ad167929

@Kalyse pouvez-vous m'envoyer un email ? [email protected]

À votre santé

Peut-être qu'il faut des développeurs de confiance supplémentaires qui peuvent approuver les demandes d'extraction ?

@cloudhead J'utilise WinLess pour compiler mon code LESS... WinLess est livré avec la dernière distribution de less.js (voir https://github.com/marklagendijk/WinLess/issues/14), donc n'importe quelle idée quand cela (et d'autres correctifs ) sera ajouté à la dernière version ?

Merci (pour un excellent produit).

alors, euh, euh... Comment ça se passe ?

@jreading, je pense que cela a été corrigé dans git avec commit cb7893

Apparaît corrigé (ou du moins le problème d'origine est) et sinon, je suis sûr qu'il y a un autre bogue pour couvrir cela.