Less.js: propriedades duplicadas ao @importing várias vezes (aninhado @import)

Criado em 25 jun. 2010  ·  49Comentários  ·  Fonte: less/less.js

Master @imports A e B,
B @imports A

Ao usar um mixin de A no arquivo mestre, as propriedades são duplicadas

Veja o teste de unidade para mais informações

Configuração: lessc cli versão 1.0.21 no ubuntu 10.04

Todos 49 comentários

Eu acho que o problema é que o arquivo é importado duas vezes, esse é o comportamento correto para mixins.

Você acha que deveria importar o arquivo duas vezes? Caso contrário, também deve levar em consideração os URLs relativos. Por exemplo

// 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, gostaria de saber se há uma maneira mais fácil de verificar se um arquivo é igual a outro arquivo. Talvez algo nos cabeçalhos.

O tamanho do arquivo é um indicador barato e provavelmente único em qualquer conjunto de arquivos de origem. No entanto, é _possível_ ter 2 arquivos com o mesmo tamanho.

Da mesma forma com a data de modificação.

Se o servidor definir o cabeçalho ETag, você pode / deve usá-lo.

Usamos o hash MD5 do conteúdo do arquivo como a chave ao armazenar em cache, mas eu pessoalmente acho isso um exagero.

hmmm, sim, o problema é que o javascript não tem MD5 nativo, ou eu usaria isso ..
A ETag seria ideal, mas alguns servidores não a configuram. Vou ter que pensar sobre isso.

Parece que concordamos que os arquivos não devem ser importados duas vezes. No entanto, é sempre verdade? (ou seja, com a ajuda do scope, importar em um mixim pode ser ok - cloudhead você pode responder melhor do que eu sobre este).

Muitos idiomas já resolveram esse problema de maneiras diferentes:

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

O "caminho C" pode ser um pouco mais difícil de implementar, mas os condicionais podem oferecer outras grandes possibilidades.

Se a "maneira do PHP" for escolhida, precisamos escolher uma forma de diferenciar os arquivos. O URL absoluto parece uma boa escolha (podemos tê-lo diretamente ou via document.location + URL relativa) - acho que é melhor do que size / length / MD5 porque não consome uma solicitação HTTP.
No entanto, pode não ser suficiente: cada URL é mapeado para um único arquivo, mas cada arquivo pode ser mapeado para vários URLs. Nesse caso, a introdução de uma nova palavra-chave @<strong i="16">@name</strong>: <unique name> pode ajudar.

O algoritmo @import_once seria então: se a URL absoluta ainda não foi importada, pegue os arquivos e verifique se o @ @name já foi importado, se não importe o arquivo.

Eu concordo. dentro do contexto de uma única solicitação, você deve ser capaz de presumir que os recursos não mudam. portanto, os urls absolutos devem ser bons o suficiente.

verificar se há alterações no arquivo é outra questão.

acho que devemos manter @import import várias vezes porque é assim que o @import original funciona,

eu gosto da solução semelhante a php do @vicb , mas em vez de

podemos adicionar algo assim na parte superior do arquivo .less:
/ _! requer: url (./abc.less)_/

Também estou enfrentando esse problema. Meu projeto tem uma hierarquia de arquivos LESS compilados em um único arquivo .css. Existe um arquivo LESS do utilitário que é incluído em vários arquivos, no resultado final todos os mixins são duplicados a mesma quantidade de vezes que o arquivo do utilitário foi importado.

Um @import_once , ou talvez @import : once url ('url'); resolveria esse problema.

Estamos enfrentando o mesmo problema que @NielsJanssen em nosso projeto, alguma ideia de quando esse problema será corrigido?

Também enfrentando esse problema. Alguém descobriu uma solução?

Tenho o mesmo problema aqui. Não consegui encontrar uma solução simples, acabei reorganizando as importações para que não sejam importadas duas vezes.

Eu realmente sugiro verificar o Stylus se você usar node.js. Usei LESS por um tempo, fiquei frustrado com sua total falta de desenvolvimento, mudei para o SASS e finalmente para o Stylus. Realmente acerta os recursos, a sintaxe é opcional (e eu uso um meio-termo), é muito poderosa e o TJ é um desenvolvedor realmente responsivo.

Se você não usa node.js, você ainda pode usar Stylus com ruby ​​e compilar em sua máquina. E se você não gosta da Stylus por algum motivo, SASS / SCSS também é uma boa alternativa e pode ser feito da mesma forma.

Resumindo: LESS não é bom no longo prazo.

Muito má atitude, cara.

Não é necessário postar esse bs aqui. Você poderia ter enviado por correio ou algo parecido. Você não pode ter padrões tão elevados como querer um "desenvolvedor realmente responsivo" para algo que seja de uso gratuito.

Absolutamente não.

Eu teria adorado esse conselho quando descobri o LESS pela primeira vez, para não perder semanas do meu tempo me acostumando com ele e me convertendo a ele e a partir dele quando finalmente saí. É verdade que eu deveria ter percebido primeiro, pois há mais questões abertas do que encerradas, e a maioria delas não foi respondida.

Não se trata de quais padrões eu posso ou não posso ter. Trata-se de alertar as pessoas, quando houver alternativas melhores.

Portanto, mantenho meu "BS" e espero que as pessoas considerem o aviso útil.

@ianstormtaylor : dizer que um projeto "não é bom a longo prazo" é um pouco histérico.

tendo esse mesmo problema também.

foo.less

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

bar.less

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

baz.less

<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;
}

Fiquei fora dessa discussão antes, mas agora que estou enfrentando o mesmo problema ... @wlangstroth , não acho que @ianstormtaylor esteja histérico. basta verificar a lista de problemas em aberto para este projeto e há quanto tempo alguns deles estão abertos. less é uma ferramenta útil, mas acho que é uma avaliação justa que o suporte é limitado e que pode ser muito frustrante durante a espera.

tenho a impressão de que @cloudhead ignora quase todos os comentários que faço (talvez eu esteja errado sobre isso), mas seria melhor ouvir "estou ocupado" ou "não quero consertar isso" ou mesmo algo mais severo em vez de não obter resposta alguma.

Você _poderia_ ter apenas um arquivo main.less contendo todas as suas importações. Veja o bootstrap do bootstrap.less ).

alguns dos menos arquivos que eu importo (de uma biblioteca externa) são escritos para serem compilados de forma autônoma, de modo que cada um inclui um variables.less e o problema que estou vendo ocorre porque eu importo cada um deles menos arquivos em um arquivo principal e, em seguida, compilar esse arquivo aplica cada mixin tantas vezes quanto os mixins são incluídos (uma vez para cada arquivo que incluo da biblioteca externa).

Você está certo - i _could_ fazer algo como você sugeriu e eu _am_ fazer algo assim no código eu tenho total controle sobre, mas que não faz média todo mundo faz assim.

Além disso, uma solução alternativa (_somente_ se eu não estivesse usando uma biblioteca de terceiros) não altera o fato de que se trata de um bug. Fiquei bastante familiarizado com a forma de contornar problemas com menos, mas é frustrante que bugs como esse estejam abertos há quase 18 meses. ( @wlangstroth, eu percebo que não é _sua_ culpa)

para quem estiver interessado, eu tenho uma correção de força bruta (não testada contra o teste de @vicb , mas deve funcionar) que colei em um comentário no # 431. Vou tentar encontrar uma solução melhor se tiver mais tempo.

tendo o mesmo problema

Também tive esse problema, mas resolvi importando minhas bibliotecas mixin para o bootstrap.less. Não sabia que as importações subsequentes teriam acesso a eles, mas faz sentido.

fyi # 431 é uma solicitação pull que corrige esse problema

@cloudhead Você seria capaz de aplicar uma correção para isso. Este é provavelmente um dos problemas mais antigos que ainda estão em aberto. Seria bom ver isso resolvido.

O mesmo problema :-(

Como sugestão para qualquer pessoa que esteja tendo problemas com esse problema, recomendo que você deixe uma mensagem para Alexis no Twitter. Alexis disse anteriormente em vários tíquetes que ele não pode monitorar todos os problemas e realmente só corrige quando é informado da gravidade. Considero que este é um problema grave, mas não fui capaz de chamar a atenção de Alexis no Twitter.

Talvez outra pessoa tenha mais sorte.

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

E solte um link para este problema: https://github.com/cloudhead/less.js/issues/49

@Kalyse se @cloudhead não pode monitorar adequadamente os problemas deste projeto, então é ainda mais uma razão para que todos evitem usá-lo. pessoas sugeriram que ele deveria nomear outras pessoas para ajudar a gerenciar o acúmulo de problemas, mas novamente não houve resposta.

por que eu deveria usar o twitter para chamar a atenção de alguém quando essa pessoa já pode receber alertas quando eu menciono essa pessoa em uma edição? Acho vergonhoso que @cloudhead não consiga responder a questões que estão abertas há 2 anos - ele poderia pelo menos encontrar algumas pessoas em quem confia e fazer com que elas comecem a trabalhar com o acúmulo de questões em aberto. eles poderiam pelo menos fechar duplicatas e ajudar a reduzir o número de questões abertas para ele.

O sistema de notificação do github é completamente inútil - eu recebo cerca de 70 a 100 notificações por dia, então prefiro simplesmente ignorá-las.

Vou investigar isso ..

Ok, adicionei uma diretiva @import-once - é bem rudimentar, pois só verifica se os caminhos correspondem - mas deve abranger a maioria dos casos de uso.

@cloudhead Que bom que você

Eu pessoalmente não entendo por que este projeto está no Github se as solicitações de pull nem sequer são consideradas ou por que o rastreador de problemas ainda está em execução se os problemas forem ignorados.

Calma gente! Se qualquer pessoa tivesse um projeto tão popular, estaria no mesmo barco. @cloudhead fez um ótimo trabalho e talvez precise adicionar algumas pessoas de confiança como administradores. Mas os problemas com solicitações pull e testes são muito mais úteis do que problemas isolados. Talvez conserte alguns problemas enquanto você está relaxando.

As pessoas consertaram muitos problemas, às vezes anos atrás. Verifique uma das 74 solicitações de pull pendentes sem resposta. Por exemplo, este mesmo problema tem muitos idiotas desde 2 anos (como # 324 # 71). Aqui está uma solicitação de pull que teria corrigido esse problema de forma bastante simples: https://github.com/cloudhead/less.js/pull/431O commiter pediu feedback, foi recebido com silêncio e, finalmente, desistiu.

@cloudhead - Alexis, este é um projeto muito grande para deixá-lo em mau estado. Quando as pessoas veem o tipo de coisa mencionada acima, elas ficam com a impressão de que o projeto não é confiável ou não é confiável. E é desnecessário! A mágica do github é que você pode facilmente encontrar algumas pessoas que estão escrevendo um ótimo código e interessadas em se comprometer com o projeto. Pergunte a essas boas pessoas se elas ajudarão a moderar problemas e obter solicitações.

Todos nós amamos o seu trabalho. A comunidade quer ajudar. Deixe-nos ajudar!

@jeremyricketts, bom ponto.

Concordo com @jeremyricketts - em uma empresa para a qual trabalho, acabamos não

@cloudhead parece que a diretiva @import-once não funciona, este é o meu caso de teste.

// 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();
}

depois de compilar o c.less , o resultado esperado deve ser

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

mas eu tenho as propriedades duplicadas

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

+1 jeremyricketts

É necessário alguém com alguma habilidade de programação real. Meu mundo é PSD's, lápis e papel, e html CSS e trabalho light jQuery.

Algumas pessoas são necessárias apenas para fazer a triagem dos problemas e solicitar solicitações,
podar duplicatas, certificar-se de que há casos de teste para bugs, etc. Eu gostaria
me voluntariar para ajudar no mínimo, e provavelmente posso ajudar
feche os bugs menores também.
Em 23 de março de 2012, 13h28, "Jeremy Ricketts" <
[email protected]>
escreveu:

É necessário alguém com alguma habilidade de programação real. Meu mundo é do PSD,
lápis e papel, e CSS html e trabalho leve do jQuery.


Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/cloudhead/less.js/issues/49#issuecomment -4667283

@cloudhead Apenas no caso de você estar se esforçando para pensar em uma boa solução para isso, você deve dar uma olhada na resolução @neonstalwart de um tempo atrás.

Basicamente, as regras nunca devem ser adicionadas aos seletores se houver uma regra existente com o mesmo valor da propriedade atual. Você também deve verificar o valor da propriedade, já que com planos de fundo, você pode adicionar vários planos de fundo diferentes, uma vez que eles são tratados de maneira diferente em navegadores diferentes.

O que você acha desta solução @cloudhead
Parece o caminho a seguir?

Não corrigir isso significa:

1) Os arquivos são maiores do que precisam ser.
2) Espalhar seu CSS por vários arquivos e importar lotes torna-se indesejável porque cada vez que você inclui um arquivo adicional que também inclui os mixins, você está adicionando os valores daquele mixin novamente. Tenho talvez 80 estilos menos CSS, e isso significa que quando faço uma mixagem de gradiente .background (), resulta em 80 * 6 estilos adicionais para cada seletor. (6 para oferecer suporte a todos os navegadores diferentes).
3) Também retarda a renderização da página. Meus desenhos / atualizações por segundo caem drasticamente por causa dos estilos adicionais.

Pensamentos @cloudhead ?
Saúde.

@cloudhead Se fizermos uma solicitação pull para esse problema a partir do commit mais recente, você examinará a fusão?

@Kalyse você pode me [email protected]

Saúde

Talvez o que seja necessário são alguns desenvolvedores confiáveis ​​adicionais que podem aprovar solicitações pull?

@cloudhead eu uso WinLess para compilar meu código LESS ... WinLess vem com a distro mais recente de less.js (veja https://github.com/marklagendijk/WinLess/issues/14), então qualquer ideia quando isso (e outras correções ) será adicionado à versão mais recente?

Obrigado por um ótimo produto).

então, er uh ... Como vamos fazer sobre isso?

@jreading , acho que foi corrigido no git com commit cb7893

Parece corrigido (ou pelo menos o problema original está) e, se não, tenho certeza de que há outro bug para cobrir isso.

Esta página foi útil?
0 / 5 - 0 avaliações