Вы имеете в виду псевдоселектор :empty ?

http://reference.sitepoint.com/css/pseudoclass-empty

Нет, наверное, надо было назвать это "правилом";)
Я имею в виду это

.selector {}
a.nother{
   .selector {}
}

Они удаляются при компиляции в css

Зачем вам их хранить? Они не делают ничего, лежащего в пустом месте в сгенерированном файле CSS. Вы говорите, что пытаетесь стилизовать с помощью Firebug, но я не понимаю, каков ваш подход.

1. Я создаю пустые правила в файле less для элемента или группы элементов.
2. Я открываю firebug, выбираю элемент, над которым собираюсь работать, и вижу созданные мной пустые правила.
3. Я пишу стили внутри этого пустого правила
4. Плагин https://github.com/ronniekk/css-x-fire синхронизирует изменения, внесенные мной в firebug, в файл less, он находит пустое правило и помещает туда стили, указанные в firebug.

Требование состоит в том, что правило должно уже существовать, чтобы плагин мог правильно синхронизироваться, и, очевидно, если у элемента раньше не было стилей, мне придется создать пустое правило в первый раз. Это работало, когда я использовал чистый CSS, но теперь, когда я переключился на LESS, я понял, что компилятор удаляет пустые правила, и плагин не может синхронизировать стили.

Я понимаю, что это довольно узкий вариант использования ...

Это похоже на очень конкретный вариант использования. В большинстве случаев люди предпочли бы МЕНЬШЕ оптимизировать свой CSS и _did_ не оставлять пустые правила.

Я бы посоветовал использовать less.watch() для автоматического обновления ваших стилей:

<script type="text/javascript">
     less.env = "development";
     less.watch();
</script>

или добавьте #!watch к своему URL-адресу.

Если у вас есть проблемы, здесь есть несколько предложений: http://www.paulsprangers.com/2011/04/quick-tip-less-js-in-development-and-watch-mode/

Хороший совет от @Soviut. также, если вам это не нравится, для обхода добавьте поддельное правило, например

temp: ruleset;

Согласовано. Решение @agatronic делает то, что вам нужно, не заставляя все остальные файлы LESS генерировать неэффективный CSS.

@agatronic это то, что я делал последние 2 недели с тех пор, как начал использовать LESS, но несколько раз такие поддельные правила попадали в производство, потому что я забыл их удалить, поэтому я подумал, может быть, есть более четкий способ исправить это :(

@Soviut, к сожалению, это совершенно другой рабочий процесс, я не готов отказаться от него из-за использования Less ... также использование меньшего количества компилятора в браузере вызвало серьезные проблемы с производительностью, загрузка страницы увеличилась с 500-700 мс до 2-3 с ..

Я понимаю, что эта опция не будет добавлена, и я согласен с вами, но если это не проблема, вы можете сказать мне, пожалуйста, в каком файле исходного кода я могу изменить поведение самостоятельно?

попробуйте изменить это

https://github.com/cloudhead/less.js/blob/master/lib/less/tree/ruleset.js#L187

@chetzof Я

я сказал так:

селектор {/ ** /}

он будет пустым на firebug.

@ d4ng3rmax Классная точка!
Я думаю, что у меня тот же рабочий процесс, о котором упоминал
Спасибо.

Эта вещь обязательна для использования во время разработки с css-modules .
На самом деле утомительно настраивать все селекторы во время строительных лесов, а затем умудряться их удалить.

.main {
/*! keep */
}

.loading {
/*! keep */
}

.button {
/*! keep */
}

.form {
/*! keep */
}

@garkin Каковы ваши аргументы /

В противном случае они были бы undefined на этапе импорта.

import * as React from 'react'
import * as cx from 'classnames';
import css from './home.less';

export class Home extends React.Component {
    render() {
        const isLoading = true;
        return <div className={cx(css.main, {
            [css.loading]: isLoading
         })}>
            Home
        </div>
    }
}

Это приводит к исключениям во время выполнения и разрушает горячую замену модуля. Предотвращение удаления селекторов устраняет все эти проблемы.
Но во время сборки вы всегда должны помнить, что селекторы будут удалены, и вам нужно бороться с компилятором, чтобы предотвратить это. И тогда все эти /*! keep */ комментарии необходимо удалить когда-нибудь в будущем.

@garkin Хм ... разве не нужно просто закончить писать таблицу стилей? Я говорю, что это проблема, вызванная только таким подходом к разработке.

Например, там, где я работаю, мы используем Less и Sass в зависимости от команды, а в нашей текущей настройке сборки Sass пустые селекторы не проходят линтинг (приложение не компилируется). Поэтому я был вынужден просто изменить свой подход с помощью модулей CSS / React.

На самом деле проблема в следующем:

{
     [css.loading]: isLoading
}

Если вы измените этот шаблон, это не вызовет исключения:

<div className={`${isLoading && css.loading}`}></div>

В вашем примере вы пытаетесь определить свойство объекта с именем, которое может быть неопределенным. Если вы переключите логику, ваш класс может быть неопределенным, и исключение не возникнет.

Это так называемое «завершение написания таблицы стилей» требует определенного когнитивного контекста и может занять значительное время. Это намного проще сделать после этапа создания строительных лесов, имея под рукой разметку и работающую HMR.

Этот шаблон является доминирующим и полуофициальным руководством по использованию, он был частью дистрибутива React некоторое время назад.
И этот образец явно дистиллированный. Ваш путь не читается и не масштабируется.

return <div className={cx(css.post, sharedCss.frame, {
    [css.support]: post.isSupport,
    [css.foreign]: showTranslation,
    [css.private]: post.isInternal,
    [css.cached]: post.status.isLoading
    ...
})}>...</div>

CSS-модули - это основной подход к созданию стилей в наши дни, и в будущем их станет еще больше.
Удаление пустых селекторов - запутанно изменяет семантику кода при использовании с css-модулями.

Такого поведения следует, по крайней мере, избежать с помощью конфигурации.

Это интересно. Повторное открытие не столько для этого случая использования, сколько потому, что Less не должен заниматься «чисткой» CSS. Опция compress устарела по аналогичным причинам, т.е. существует множество поддерживаемых инструментов, которые удаляют селекторы / сжимают / добавляют префиксы и т. Д.

Вероятно, такое поведение было создано, когда пустой селектор не имел отношения к браузеру, но в некоторой степени справедливо, что он не имеет значения как данные, когда вы учитываете модули CSS.

На самом деле, если кто-то не возражает, я думаю, что это безопасно реализовать как вариант. ИМО, это будет removeEmptyRulesets (не селекторы) со значением по умолчанию true .

Изменить: или это должно быть keepEmptyRulesets со значением по умолчанию false ? 🤔 Вероятно, последнее, так как упрощает проверку на ложность при неопределенном состоянии.

когда вы учитываете модули CSS

И это не ограничивается только ими. Также рассмотрите такие вещи, как программный доступ через CSSOM .

Я бы сказал, что keepEmptyRulesets - хороший вариант для добавления.
Может быть, немного многословен. Не очень хорошо для CLI: --keep-empty-rulesets

Немного многословно, может быть

Я не возражаю, но у вас есть альтернативное предложение? Это кажется очень специфическим поведением, поэтому иногда полезно быть откровенным. Ничто не мешает ему быть keepEmptyRulesets в API и --keep-rulesets в CLI. Или даже --keep-empty

Должен ли он быть просто keepEmpty для обоих?

Я хотел бы использовать:

1. outputEmptyRulesets : true|false качестве параметра API;
2. --empty-rulesets как переключатель полной формы CLI; а также
3. -er или, возможно, -empty в качестве сокращенного переключателя CLI.

@rjgotten Я не @garkin - как ты к этому

Мне подходит.

Когда можно ожидать его реального воплощения?
Это проблема и для нас.

Приветствуем PR @orchidoris !

Плагин временного решения ...

Добавляет __NOOP__: 1; к каждому селектору, а затем удаляет их после того, как сделано меньше.

class NoopPreProcessor {      
    process = (css, extra) => css.replace(/}/g, ';__NOOP__: 1;}');                                                                      
}      

class NoopPostProcessor {      
    process = (css, extra) => css.replace(/__NOOP__: 1;/g, '');                                                                               
}                                                                                                                       

const NoopPlugin = {                                                                                                    
    install: (less, pluginManager) => {                             
        pluginManager.addPreProcessor(new NoopPreProcessor());        
        pluginManager.addPostProcessor(new NoopPostProcessor());      
    },                                                                
}; 

Для preact с меньшим загрузчиком:

    helpers.getLoaders(config)                                                             
        .filter(item => item.ruleIndex===1)      
        .map(item => {                           
            item.loaders[0].options.options.stictMath = true;      
            item.loaders[0].options.options.plugins = [            
                NoopPlugin,                                        
            ];                                                     

            item.loaders[0].options.options.paths = [      
                ...item.loaders[0].options.options.paths[0],      
                path.resolve(__dirname, 'src'),                   
            ];                                                    
        });