Я вроде тоже самое написал. У нас вся сборка происходит на специальном для этого сервере. Доступ в сеть есть только на ограниченное количество адресов. Если требуемого пакета нет, то загружаем из сети, но в большинстве случаев такой потребности не происходит поскольку пакеты в локальное хранилище добавляются на этапе разработки (при первой же сборке проекта, а потом уже могут браться из кеша). Все конечно же хранится локально. Собственные пакеты тоже все лежат в этом хранилище.
До 3-й версии npm, shrinkwrap.json собирал дерево зависимостей из package.json, как сейчас не скажу. Но учитывая тот факт, что можно указать ссылку на тот же github (если пакет был отозван или npm не может найти требуемую версию, то они пытаются её засосать с github'a) зависимости явно не будет залоченными.
Также со shrinkwrap.json всегда было огромное количество проблем из-за его генерации. Например, я сейчас создал файл с одной зависимостью от "coffee-script": "1.10.0" и вот что я получил при попытки создать дерево зависимостей:
У меня лично нет времени разбирать такие проблемы (а это напомню — всего один пакет в зависимостях).
Но самое забавное то, что npm, все-таки сгенерировал shrinkwrap.json, правда в нем куда меньше зависимостей.
Привет!
Собственное локальное хранилище пакетов (registry), которое должно уметь подсасывать пакеты из официального хранилища (если пакета еще нет или отсутствует требуемая версия) + bundledDependencies (если есть необходимость) + GitLab или что-то в этом духе.
В умелых руках, при наличии собственного локального хранилища npm-пакетов символы типа ^ незаменимы.
А вот shrinkwrap.json практически бесполезная вещь. Возможно вы не обратили внимание, но в нем тоже полно пакетов с "плавающими" зависимостями. Вместо этого обратите внимание на bundledDependencies.
Проблема даже не в самом npm, а registry (хранилище пакетов).
# Проверяем путь к хранилищу пакетов
➜ npm get registry
http://registry.npmjs.org/
# Устанавливаем пакет в альтернативное хранилище:
➜ npm install --registry="https://путь к вашему локальному хранилищу"
В таком случае, никаких претензий не будет, поскольку все файлы будет храниться в том месте где вам удобно.
Также есть IPFS...
Вот в случае HTML мне бы пришлось помучаться, т.к. закрывающие теги могут располагаться сильно далеко от открывающих.
Это как раз не проблема, IDEA показывает текущую позицию курсора (относительно документа, родителя и текущего элемента — зависит от позиции курсора и выбора элемента):
Потеряться с такими подсказками невозможно, а с Jade проще-простого. Если у элемента много модификаторов и прочих атрибутов, которые выставляются по различным условиям, то разметка Jade превращается в "мясо". Ориентироваться в таком коде без подсказок со стороны редактора крайне сложно.
В XML-e все элементарно — открыл элемент и добавляешь нужные атрибуты по различным условиям, в Jade это реально будет нечитаемые и неподдерживаемый код!
К тому же авто-форматирование может привести код не к тому виду, который хотелось бы, особенно в случае больших тегов (много-много аттрибутов).
Не знаю о каких проблемах вы говорите, потому что автоформатирование настраивается и как жить без него вообще не представляю.
PS: У нас получается какой-то спор ради спора, только вот я реально понимаю на собственном опыте, что Jade непригоден для серьезных проектов — вообще не пригоден. Это сложно понять если вы делаете промо-странички, в которых нет тем, модификаторов, массы атрибутов, которые выставляются по условиями и пр.
Вы предлагаете разбивать код на мелкие фракции тем самым внося путаницу в существующую архитектуру. И более такого, это еще и увеличит объем результирующего кода, поскольку каждый миксин к этому обязывает. Конечно же есть какие-то общие блоки, которые могут выставлять базовые атрибуты, но просто так код никто не станет дробить на мелкие кусочки чтобы решить проблему шаблонизатора…
Писать код с Jade быстрей вы не станете ибо есть Emmet. Наглядности он тоже никакой не даст если коде конечно не теги с одним атрибутом. Дальше, все — только ограничения.
Еще раз повторюсь — Jade не решает ни одной проблемы, а только создает.
(1), (2) — по этим параметрам можно завернуть любой мало-мальски свежий язык.
Jade не такой уж и новый язык. Те же JetBrains практически всегда прислушиваются к сообществу в плане поддержки той или иной возможности. Примером этому служат Stylus и Sass. C Jade, увы, это не произошло.
(3) — пожалуйста, разъясните, имеется ввиду скомпилированный в JS код? В чем заключается неэффективность?
Код, который заранее компилуется в JS для исполнения в рантайме. Я с Jade давно расстался поэтому пример уже не приведу.
(5) — конечно можно работать без шаблонизатора, это минус шаблонизатора?
Если вы имеете ввиду что-то вроде React JSX, то да, это отличный пример!
(6) — все таки если работать без редактора — то Jade все таки помогает снизить вероятность получить невалидный HTML с точки зрения закрывающих тегов.
К сожалению, интеграционные тесты довольно часто отстают от релиза. Это дает потенциальную возможность внести баг при неправильном разрешении конфликтов (в больших проектах релиз-инженер может собирать релиз до 3-х недель и допустить ошибку в запарке вполне реально. Если конфликты разрешает сам разработчик, то это тоже не исключает ошибок — проходили и ни раз).
Вложенность — это значимая единица языка, как в python. Те кто пишут на питоне вменяют этому параметру минус?
Я уже отвечал на этот вопрос. Поскольку я сам пишу на Python, то подобных проблем с редакторами нет, да и сам программный код значительно читабельней нежели разметка.
Но разве плохо использовать этот язык для проектов, где разработчик один? Этот язык настолько плох, что не решает совершенно ни одной задачи?
Любое решение, должно решать какую-то проблему. А Jade по своей сути ничего не дает кроме накладных расходов.
Из опыта могу сказать, что следует использовать то решение, которое позволит запустить проект без создания новой системы. Здесь я имею ввиду, что если вы привыкли использовать Jade для создания промо-страниц, и вам дали заказ на "завод", то вы потратите огромное количество времени на получение опыта в поисках правильного решения.
Иными словам, перед тем как выбрать тот или иной продукт нужно составить таблицу с требованиями, противоречиями и критериями проверки выполнения условий. Если Jade удовлетворяет всем вашим критериям, то проблем нет…
Я ведь тоже когда-то повелся на лаконичный синтаксис Jade и HAML))
Если позволите, то я бы хотел добавить, что такие препроцессоры как SASS, Less и Stylus весьма активно используются в больших корпорациях. А все потому, что они реально решают конкретные проблемы. Jade не решает ни одну из проблем!
Вместо этого он их создает:
Отсутствие полноценной интеграции с редакторами
Требуется обучение сотрудников
Крайне неэффективный результирующий код для динамической шаблонизации.
Сложно интегрируется с другими шаблонизаторами
— В том же Django использование pyJade несет огромные накладные расходы на компиляцию в рантайме, а прекомпиляция Jade под Djando тот еще гемморой.
— Также, во многих шаблонизаторах принято давать расширение шаблонам типа *.tpl (если рассматривать Jade как подсистему). На сколько я помню, в Jade шаблоны которые экстендятся должны быть без расширения или иметь расширение *.jade. Возможно эту проблему уже решили, но она была точно.
— Попытка прикрутить Jade к React вместо JSX выглядит как какой-то оксюморон
Лишние накладные расходы (в серьезных проектах стараются максимально сократить количество зависимостей в CI)
Из-за слабой поддержки редакторами повышается вероятность возможных ошибок (с идентацией это более чем правда).
Сборка с помощью grunt-contrib-jadeневозможна (позавчера закрыли таск, который был поставлен 2 года назад, и то не факт, что починили!).
grunt-contrib-jade делает экспорт только в AMD. Попытки сделать кастомный экспорт не находят поддержки.
Это чисто недостатки по каким-то отрывочным воспоминаниям, но даже их достаточно чтобы не использовать этот шаблонизатор.
Отсутствие полноценной поддержки в редакторах это один из минусов — весьма существенный, но не далеко не единственный.
Лично я и еще ряд моих коллег сделали однозначный вывод, что Jade непригоден для использования в серьезных проектах. Этому подтверждению есть разумные объяснения, которые я привел выше.
Проект долгое время не развивался, баги не фиксили. И я не слышал ни об одной серьезной компании где бы его использовали.
Мне тоже не нравится XML, но есть вещи, которые нужно выбирать проводя сравнительный анализ. В Jade только компактный синтаксис, на этом его преимущества заканчиваются.
Мы видимо друг-друга совсем не понимаем… вы работали с очень большими хайлоад проектами, которые весят по 600мб?
Все в миксины не вынести, хотя бы потому, что это значительно увеличивает объем результирующего кода. Переписать весь старый код тоже никто не позволит. Да и этот микроменеджмент никому не сдался — куча папок и файлов не решают основных проблем.
Например, у нас сейчас в проекте такая БЭМ-структура:
блок
__элемент
_модификатор
И даже с такой простой структурой каждая папочка создает массу накладных расходов.
Это только ОДИН блок, который еще не скомпелирован!
Так вот, если понадобится перенести .baz на уровень .foo, то .baz придется выравнивать по .bar. Если вложенность будет глубокая, то это может создать трудности, поскольку закрывающего элемента нет и ориентироваться придется по коллапсингу (сворачивая последовательно блоки).
В XML этой проблемы не будет, можно даже и не форматировать код (⌥⌘l) — он просто будет работать.
Проще, потому что нам не нужно искать закрывающие теги.
Зачем искать закрывающийся тег? Если это действительно нужно, то клик по тегу в большинстве редакторов решает проблему.
Но да, с кодом нужно работать более аккуратным образом в плане отступов. Почему вы этому пункту вменяете недостаток — неясно.
В программном коде я сторонник идентации, но в разметке код становится менее читабельным (на мой вгляд). Если в программном коде не вызывают вопросы лишние переводы строк, то в разметке они выглядят нелепо, а без них код с большой вложенностью напоминает "ёлочку".
Это лично мои ощущения и к недостаткам я идетацию как таковую не относил.
Так и не понял чего не может случиться.
Синтаксис Jade при отсутствии постоянной практики забывается на раз, XML забыть невозможно. И это очень важно, особенно когда проект большой и люди в нем регулярно меняются. Как минимум не требуется время на изучение особенностей синтаксиса.
Также со shrinkwrap.json всегда было огромное количество проблем из-за его генерации. Например, я сейчас создал файл с одной зависимостью от "coffee-script": "1.10.0" и вот что я получил при попытки создать дерево зависимостей:
У меня лично нет времени разбирать такие проблемы (а это напомню — всего один пакет в зависимостях).
Но самое забавное то, что npm, все-таки сгенерировал shrinkwrap.json, правда в нем куда меньше зависимостей.
Собственное локальное хранилище пакетов (registry), которое должно уметь подсасывать пакеты из официального хранилища (если пакета еще нет или отсутствует требуемая версия) + bundledDependencies (если есть необходимость) + GitLab или что-то в этом духе.
А вот shrinkwrap.json практически бесполезная вещь. Возможно вы не обратили внимание, но в нем тоже полно пакетов с "плавающими" зависимостями. Вместо этого обратите внимание на bundledDependencies.
В таком случае, никаких претензий не будет, поскольку все файлы будет храниться в том месте где вам удобно.
Также есть IPFS...
Это как раз не проблема, IDEA показывает текущую позицию курсора (относительно документа, родителя и текущего элемента — зависит от позиции курсора и выбора элемента):
Потеряться с такими подсказками невозможно, а с Jade проще-простого. Если у элемента много модификаторов и прочих атрибутов, которые выставляются по различным условиям, то разметка Jade превращается в "мясо". Ориентироваться в таком коде без подсказок со стороны редактора крайне сложно.
В XML-e все элементарно — открыл элемент и добавляешь нужные атрибуты по различным условиям, в Jade это реально будет нечитаемые и неподдерживаемый код!
Не знаю о каких проблемах вы говорите, потому что автоформатирование настраивается и как жить без него вообще не представляю.
PS: У нас получается какой-то спор ради спора, только вот я реально понимаю на собственном опыте, что Jade непригоден для серьезных проектов — вообще не пригоден. Это сложно понять если вы делаете промо-странички, в которых нет тем, модификаторов, массы атрибутов, которые выставляются по условиями и пр.
Вы предлагаете разбивать код на мелкие фракции тем самым внося путаницу в существующую архитектуру. И более такого, это еще и увеличит объем результирующего кода, поскольку каждый миксин к этому обязывает. Конечно же есть какие-то общие блоки, которые могут выставлять базовые атрибуты, но просто так код никто не станет дробить на мелкие кусочки чтобы решить проблему шаблонизатора…
Писать код с Jade быстрей вы не станете ибо есть Emmet. Наглядности он тоже никакой не даст если коде конечно не теги с одним атрибутом. Дальше, все — только ограничения.
Еще раз повторюсь — Jade не решает ни одной проблемы, а только создает.
Jade не такой уж и новый язык. Те же JetBrains практически всегда прислушиваются к сообществу в плане поддержки той или иной возможности. Примером этому служат Stylus и Sass. C Jade, увы, это не произошло.
Код, который заранее компилуется в JS для исполнения в рантайме. Я с Jade давно расстался поэтому пример уже не приведу.
Если вы имеете ввиду что-то вроде React JSX, то да, это отличный пример!
К сожалению, интеграционные тесты довольно часто отстают от релиза. Это дает потенциальную возможность внести баг при неправильном разрешении конфликтов (в больших проектах релиз-инженер может собирать релиз до 3-х недель и допустить ошибку в запарке вполне реально. Если конфликты разрешает сам разработчик, то это тоже не исключает ошибок — проходили и ни раз).
Я уже отвечал на этот вопрос. Поскольку я сам пишу на Python, то подобных проблем с редакторами нет, да и сам программный код значительно читабельней нежели разметка.
Любое решение, должно решать какую-то проблему. А Jade по своей сути ничего не дает кроме накладных расходов.
Из опыта могу сказать, что следует использовать то решение, которое позволит запустить проект без создания новой системы. Здесь я имею ввиду, что если вы привыкли использовать Jade для создания промо-страниц, и вам дали заказ на "завод", то вы потратите огромное количество времени на получение опыта в поисках правильного решения.
Иными словам, перед тем как выбрать тот или иной продукт нужно составить таблицу с требованиями, противоречиями и критериями проверки выполнения условий. Если Jade удовлетворяет всем вашим критериям, то проблем нет…
Я ведь тоже когда-то повелся на лаконичный синтаксис Jade и HAML))
Вместо этого он их создает:
— В том же Django использование pyJade несет огромные накладные расходы на компиляцию в рантайме, а прекомпиляция Jade под Djando тот еще гемморой.
— Также, во многих шаблонизаторах принято давать расширение шаблонам типа *.tpl (если рассматривать Jade как подсистему). На сколько я помню, в Jade шаблоны которые экстендятся должны быть без расширения или иметь расширение *.jade. Возможно эту проблему уже решили, но она была точно.
— Попытка прикрутить Jade к React вместо JSX выглядит как какой-то оксюморон
Это чисто недостатки по каким-то отрывочным воспоминаниям, но даже их достаточно чтобы не использовать этот шаблонизатор.
Лично я и еще ряд моих коллег сделали однозначный вывод, что Jade непригоден для использования в серьезных проектах. Этому подтверждению есть разумные объяснения, которые я привел выше.
Проект долгое время не развивался, баги не фиксили. И я не слышал ни об одной серьезной компании где бы его использовали.
Мне тоже не нравится XML, но есть вещи, которые нужно выбирать проводя сравнительный анализ. В Jade только компактный синтаксис, на этом его преимущества заканчиваются.
Все в миксины не вынести, хотя бы потому, что это значительно увеличивает объем результирующего кода. Переписать весь старый код тоже никто не позволит. Да и этот микроменеджмент никому не сдался — куча папок и файлов не решают основных проблем.
Например, у нас сейчас в проекте такая БЭМ-структура:
И даже с такой простой структурой каждая папочка создает массу накладных расходов.
Это только ОДИН блок, который еще не скомпелирован!
Подсветка невалидных цветовых палитр:
Автокомплит цветовых палитр:
Вывод цвета прямо в атрибут:
Можно изменять название тега с закрывающего
Автокомплит по атрибутам:
По клику на элемент парная подсветка:
Резолвиг путей (автокомплит + валидация):
Где бы у меня не находился курсор абсолютно всегда понятна структура документа
C Jade, редакторы работают как с обычным текстовым файлом, а не как с полноценным проектом.
Jade
HTML
Так вот, если понадобится перенести .baz на уровень .foo, то .baz придется выравнивать по .bar. Если вложенность будет глубокая, то это может создать трудности, поскольку закрывающего элемента нет и ориентироваться придется по коллапсингу (сворачивая последовательно блоки).
В XML этой проблемы не будет, можно даже и не форматировать код (⌥⌘l) — он просто будет работать.
Ответил выше.
Зачем искать закрывающийся тег? Если это действительно нужно, то клик по тегу в большинстве редакторов решает проблему.
В программном коде я сторонник идентации, но в разметке код становится менее читабельным (на мой вгляд). Если в программном коде не вызывают вопросы лишние переводы строк, то в разметке они выглядят нелепо, а без них код с большой вложенностью напоминает "ёлочку".
Это лично мои ощущения и к недостаткам я идетацию как таковую не относил.
Синтаксис Jade при отсутствии постоянной практики забывается на раз, XML забыть невозможно. И это очень важно, особенно когда проект большой и люди в нем регулярно меняются. Как минимум не требуется время на изучение особенностей синтаксиса.