added enb-beautify for dev environment

[dab]

No description provided.

[tavriaforever]

isProd && nodeConfig.addTargets(['?.dev.html']);

[tadatuta]

+1

[dab]

🆙

[tadatuta]

@andrewblond тебе норм?

[blond]

Думаю, что не нужно делать привязку к режиму, тем более таким способом.

[dab]

В обсуждении говорили о привязке к dev-режиму. Переменная уже есть, которая знает о режиме. Чем способ странный?

[blond]

Исправил опечатку.

[tadatuta]

@andrewblond догадываюсь, что ты про что-то типа

nodeConfig.mode('development', function(nodeConfig) {
    nodeConfig.addTargets(['?.tidy.html']);
});

но если не к режиму привязываться, то к чему?

[qfox]

@tadatuta Тут явно нужно привязываться к настройкам в каждом отдельном проекте или бандле (что суть одно — явно и в make.js).

[blond]

Разделение на ?.dev.html и ?.html не прослеживается для других файлов. Из-за этого будет не очивидно, что ?.dev.html будет не минифицированный.

[qfox]

@andrewblond предлагаешь собирать в _?.html, а бьютифаером собирать ?.html? ;-)

[blond]

@zxqfox, выделение dev-файлов, на мой взгляд логично при сборке dist'а. Но при сборке обычных бандлов надо в один и тот же файл собирать по разному, при разных режимах сборки.

Но я не знаю какой режим сборки предпологает минифицированный HTML-файл, а какой забьютифаенный.

От рудимента _?.target-name — предлагаю отказаться ;)

[dab]

@andrewblond назвав файл dev — я лишь предположил это обсуждение. Планировал собирать разукрашенный код при разработке.
Если код нужно как-то допиливать руками — это явно не продакшен.

[blond]

Если код нужно как-то допиливать руками — это явно не продакшен.

@tavriaforever с тобой не согласиться ;) Если разработчик верстает, чтобы передать собранные файлы дальше, то для него production — забьютифаенный HTML-файл.

Кроме того при добавлении пробельных символов в HTML вёрстка может разъехаться из-за inline-стилей. Т.е. при переключении из одного режима в другой у нас может быть разный результат. Я не знаю как решать эту проблему правильно :(

[tadatuta]

@andrewblond

при добавлении пробельных символов в HTML вёрстка может разъехаться из-за inline-стилей

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

[dab]

@tavriaforever да, я читал его комментарий. Имхо сделать еще один «разпрекрасный» файл — выход из положения.

[qfox]

@andrewblond Продакшн тут может быть только в случае сборки готовой статики. Если дальше идет разбивка по интерполируемым шаблонам — это и не продакшн, и не dev, это что-то между, и этому желательно быть отформатированным. Еще один наиболее частый кейс — это сам процесс верстки — и здесь тоже желательно иметь красивый файл, но не обязательно. Других кейсов я в принципе не вижу.

[qfox]

Т.е. при переключении из одного режима в другой у нас может быть разный результат. Я не знаю как решать эту проблему правильно :(

Оборачивать пробелы в html-комменты? типа <!--[\n\r\t]+-->

[blond]

Оборачивать пробелы в html-комменты? типа

Что это даст? Это же нечитаемый код :)

[qfox]

@andrewblond Это решит проблему с inline стилями. Разве нет?

[blond]

Это решит проблему с inline стилями. Разве нет?

Забьютифаенный код, нужен, чтобы его читали. Если каждый пробел превратиться в <!--[\n\r\t]+--> код станет нечитаемый, и тогда нет разницы между таким способом и минифицированным файлом.

Может быть сделаем новый режим, раз это и не dev и не production по смыслу?

[tadatuta]

кажется, я придумал, что нужно сделать )
нужно переадресовать этот PR из этого репозитория в генератор и там задавать вопрос: «хотите оптимизированный html или красивый?»
и прямо там же в скобках предупреждать, что красивый он получается за счет бьютифаера и пробельные символы могут ломать инлайн-блоки. а в project-stub ограничиться ссылкой на enb-beautify.

за/против?

[qfox]

@andrewblond Можеть быть, но это один из кейсов. См. мой коммент выше — dev для процесса разработки (и он, видимо, будет ломать инлайн), production для публикации страницы в статике, и этот третий вариант — для передачи верстки дальше для интеграции (опять же, будет ломать инлайн стили).

dev и третий режимы хоть и близки, но немного про разное. В dev у нас предпросмотр результата, в третьем — файл для разбивки на шаблоны.

И на мой взгляд без решения задачи с инлайн-стилями (это значит, что бьютифаер должен много всего знать про css страницы, и про базовые display дом нод) — будет невозможно сделать универсальное решение.

@tadatuta это все равно не решает задачи с инлайном, но +1. В project-stub его можно сделать закомменченным (по аналогии со сборкой bemhtml на клиенте) — часто спрашивают.

[qfox]

Например, файл для разбивки может иметь комменты с началом и концом разных блоков — как бы намекая бэкенд разработчику, где его правильнее всего пилить. Для процесса разработки эти комментарии не нужны. Еще он может иметь лишние сбросы строк, чтобы проще было разбивать руками. В пределе он может собираться в готовые шаблоны, в т.ч. и haml, и twig, и что угодно еще. Это не задача бьютифаера, конечно, но я про режим в целом, в котором бьютифаер может быть лишь частью.

[dab]

🆙 добавил закоментированный ?.tidy.html. Убрал зависимость от окружения. Можем добавить строку про это в README файл.

[qfox]

LGTM

[tadatuta]

close in favour of bem-archive/generator-bem-stub#124