Haml: Solicitação de recurso: Importar pasta

Sou cético quanto à utilidade disso. Não acho que ter que listar manualmente todos os arquivos relevantes seja tão trabalhoso. Além disso, parece que isso pode levar ao perigo de não obter erros reais de compilação, quando um arquivo que você espera que exista não existe. Em vez disso, os estilos desaparecem aparentemente de forma arbitrária.

Eu entendo seu argumento, no entanto, não acho que você esteja vendo o outro tipo de situação em que isso é necessário. Atualmente, tenho uma pasta que terá mais de 60 arquivos Sass. Sem a capacidade de @importar uma pasta, preciso manter um arquivo que importa cada arquivo individualmente.

Existem muitos problemas em incluir cada arquivo individualmente. Em primeiro lugar, se você esquecer de incluir um arquivo, não receberá um aviso. Em seguida, se você tiver uma equipe de desenvolvedores trabalhando no Sass, cada um deles precisa se lembrar de importar o arquivo manualmente após criá-lo na pasta. Depender das pessoas para fazer a coisa certa acabará quebrando.

Além disso, temos a precedência de que importar uma pasta é uma "coisa boa". A instrução de importação do Java permite importar pacotes inteiros ou classes específicas desses pacotes.

A ordem das importações é importante no caso geral porque os seletores do mesmo peso resolvem de acordo com a ordem do documento. Globbing significa que adicionar um arquivo pode alterar a ordem de resolução global dos seletores de forma inesperada.

Esses problemas de ordenação não estão presentes no código e onde eles estão (como ruby) não existe tal recurso.

Eu estaria interessado em ver se há uma maneira de fazer isso no Sass sem alterar o mecanismo de importação do núcleo do Sass. Isso permitiria que frameworks e indivíduos usando sass desenvolvessem seu próprio sistema de globbing como desejassem. Por exemplo:

<strong i="8">@import</strong> file-list("foo/*.sass");

Costumávamos ter uma lógica de análise especial para @import que impediria isso, mas não temos mais.

O problema em permitir importações verdadeiramente dinâmicas (como por meio de funções) é que a estrutura de dependência de um documento se torna impossível de ser descoberta dinamicamente. Isso significa que o armazenamento em cache e a compilação seletiva se tornam muito menos úteis.

Para problemas de ordenação, poderíamos sempre ordenar os arquivos em ordem alfabética ou algo para chegar a uma ordenação determinística (embora arbitrária). Isso ainda apresenta o problema de que a ordem pode mudar e interromper a funcionalidade se o nome de um arquivo mudar.

Presumivelmente, tal abordagem via globbing implicaria no uso de seletores aninhados para evitar tais problemas.

Em minha opinião, importar uma árvore de diretórios inteira de arquivos tem apenas uma utilidade marginal sobre a abordagem de importação explícita e incentiva o usuário a considerar as questões de precedência. Se adicionarmos esse recurso, gostaria que fosse mais geral do que apenas no nível do diretório.

Por último, acho que você está correto ao dizer que a introdução de um glob que estava fora do gráfico de dependência e aparece como apenas importações únicas para o mecanismo sass significa que é mais difícil invalidar arquivos quando aparecem novas dependências que correspondem ao glob.

Concordo que a importação de uma pasta resultaria em uma ordem ambígua de importação de arquivos. No entanto, cabe ao usuário decidir se é a coisa certa para ele. Ele se encaixará em algumas situações, mas não em outras. Definitivamente, é possível imaginar um sistema em que o conteúdo de uma pasta não vise os mesmos elementos (o meu não).

Assim como a importação de arquivos específicos funciona. ele se encaixa em algumas situações, mas não em outras.

A escolha deve caber ao desenvolvedor.

É muito fácil para um usuário ter folhas de estilo que dependem do pedido e não saber disso. Qualquer coisa poderia desencadear uma reordenação e criar bugs de layout que seriam muito difíceis de rastrear. E não seria claro o suficiente que a importação de um diretório deixaria alguém aberto a tais questões. Ordenar por nome de arquivo provavelmente seria uma solução boa o suficiente para isso, portanto, não é um impedimento sério.

A extensão que eu consideraria permitiria globs de arquivo padrão - provavelmente aqueles suportados por Dir.glob . Isso seria resolvido em tempo de compilação e forneceria um grau razoável de poder.

Ainda estou um pouco convencido quanto à utilidade, no entanto.

É importante considerar que o pedido por meio de Dir.glob depende do sistema de arquivos e pode mudar entre as plataformas - na verdade, fui mordido por essa diferença entre Mac e Linux. Portanto, se acabarmos implementando esse recurso, é importante para nós classificar a lista de acordo com uma abordagem bem documentada e de fácil compreensão (por exemplo, classificação inferior)

Eu também ainda estou um pouco inclinado contra esse recurso. A abordagem de importação que a bússola usa não tem sido um fardo de manutenção. No entanto, é certamente um recurso comumente solicitado. Acho que já apareceu na lista de discussão e no Twitter cerca de 4 ou 5 vezes.

Certamente, iremos ordenar os arquivos de forma determinística de alguma forma. A classificação upcased vs. downcased é uma questão interessante ... provavelmente deveríamos escolher downcased com upcased como um desempatador (uma vez que permitirá empates em sistemas de arquivos com distinção entre maiúsculas e minúsculas).

Eu concordo. Eu sou contra ser capaz de passar um parâmetro diretamente para Dir.glob. Isso realmente parece ser um recurso desnecessário. Vocês podem imaginar um cenário em que seja vantajoso ter esse grau de controle?

Parece que as duas opções a seguir devem ser suficientes:
-Cherry escolher arquivos usando @import
-Importar um diretório inteiro usando @import folder_name

Além disso, acho que a ordem alfabética funcionará perfeitamente. Só precisamos ter certeza de que está documentado.

Importar diretórios via <strong i="5">@import</strong> dir é muito ambíguo com a importação de arquivos individuais. Devemos definitivamente adicionar pelo menos * globs.

Ainda não estou convencido, no entanto.

é útil se você tiver diferentes "estilos" para uma página. exemplo:
genérico / (xx arquivos sass aqui)
style1 / (xx arquivos sass aqui que adicionam / sobrescrevem estilos para os genéricos)
style2 / (xx arquivos sass aqui que adicionam / sobrescrevem estilos para os genéricos)
style1.sass (simplesmente: @import generic / _, style1 / _)
style2.sass (simplesmente: @import generic / _, style2 / _)

Por que você não poderia simplesmente ter _generic.sass que importa tudo no diretório genérico?

Não acho que seja sobre o que pode ou não pode ser feito tanto quanto deveriam. Em última análise, a ordem das folhas de estilo é importante e, por isso, quero que o usuário pense nisso. É verdade que as bibliotecas que apenas definem mixins e variáveis ​​são independentes da ordem, assim como as folhas de estilo com escopo definido - mas eu me preocupo em fornecer um recurso geral que será mal utilizado.

Definir "folhas de estilo com escopo"?

Folhas de estilo que aninham a maioria ou todos os seletores. por exemplo, body.foo

Não há garantia de que sejam independentes de pedidos. Outra folha de estilo em outro lugar poderia definir body.foo ... , ou algo com maior especificidade.

Então você realmente não tem uma estrutura de trabalho porque seus arquivos não estão separados corretamente.

Existem muitas maneiras de as pessoas bagunçarem seu CSS. Podemos fornecer a eles essa solução e explicar quando ela deve ser usada na importação de arquivos individuais.

Ao não implementar este recurso, você está dando aos desenvolvedores que desejam implementar folhas de estilo com escopo definido estas duas opções:
1) Importar manualmente cada arquivo de forma independente (o que pode causar erros porque não avisa quando você perdeu um arquivo)
2) Implementar um sistema de compilação para adicionar dinamicamente esses arquivos (o que é um desperdício porque haverá várias pessoas implementando a mesma coisa)

Certamente não é o caso de que toda a dependência de ordem das folhas de estilo com escopo seja o resultado de uma separação inadequada de interesses. Considerar:

body.foo .baz {
  color: blue; }

body.bar .baz {
  color: red; }

Esta folha de estilo está bem separada, mas ainda depende da ordem.

Em qualquer caso, a ideia de que podemos esperar que todos que usam esse recurso entendam os riscos está errada. A única maneira de garantir que todos entendam a ordem em que suas folhas de estilo serão importadas é especificando-a explicitamente.

Em geral, as folhas de estilo com escopo serão agnósticas em relação à ordem, mas pode ser que a ordem importe mesmo quando os interesses estão separados corretamente.

Ignorar silenciosamente as importações que não foram encontradas não é mais um problema no sass3. Apenas as importações de css serão ignoradas silenciosamente.

Eu tenho um arquivo sass que importa cerca de 60 outros. Eu mudo quando os arquivos são adicionados ou removidos e sempre penso na ordem quando faço isso. Nunca me pareceu um fardo, mas sim um passo necessário.

Se minhas importações não forem encontradas (eu sempre especifico .sass para importações), meus testes falham.

Existe um addage: o mais simples possível e não mais simples.

Meu instinto me diz que isso torna as coisas muito simples e toda a economia de tempo é perdida em uma sessão de depuração. Eu voto que deixemos isso de lado por enquanto. Se alguém quiser fazer um plugin sass que forneça esse recurso, eu estaria muito interessado em ver como funciona para esses usuários.

Acho que o ponto de Richard era que não há erro quando um parcial é criado, mas nenhuma importação é adicionada para ele. Suponho que isso poderia ser aliviado procurando parciais não utilizados e imprimindo avisos para eles.

Eu vou prosseguir e fechar isso.

gah, isso é péssimo ... eu tenho uma pasta chamada page_specific / nos ativos do meu aplicativo Rails ...
todos eles devem ser compilados no grande blob de ativos, e cada um deles está completamente envolvido em
body # page1 {}, body # page2 {}, etc ...

há zero chance de eles serem dependentes do pedido e, francamente, todo esse "você vai perder! Não !!!!!!" a porcaria é um insulto.

se um usuário desse recurso descobrir que a ordem é importante, ele pode apenas importar os arquivos em uma ordem explícita ou refatorar os estilos para não dependerem da ordem ... forçar todos a contornar manualmente esse recurso ausente é lixo paternalista>: (

certamente podemos pensar em uma maneira de minimizar esse pequeno problema de pedido. a ordenação determinística é um começo. chamá-lo de @ import-dir e a documentação do possível problema de pedido também ajudaria. rails já fornece require_tree, e as coisas parecem funcionar bem. a única exceção é que os arquivos são compilados individualmente, o que faz com que meus mixins e variáveis ​​caiam no chão. Eu noto que os mixins são a única parte que foi posicionada como explicitamente independente de ordem, então por que isso não pode funcionar para o atrevimento quando funciona para todos os outros?

https://github.com/chriseppstein/sass-globbing

@chriseppstein incrível! (e desculpe por reclamar como um maníaco a todos)