Комментарии 50
bower, grunt, gulp, brunch, webpack
Они все одно и то же делают?
Они все одно и то же делают?
Не совсем
bower — менеджер пакетов для клиентских библиотек
grunt и gulp — примерно одно и тоже, просто таск раннеры
brunch — не знаю что такое
webpack — бандлер и загрузчик модулей
bower — менеджер пакетов для клиентских библиотек
grunt и gulp — примерно одно и тоже, просто таск раннеры
brunch — не знаю что такое
webpack — бандлер и загрузчик модулей
- grunt и gulp по сути одно и то же, но с разным синтаксисом и подходом к написанию сценариев сборки.
- webpack в ряде случаев (но не во всех) может заменить grunt и gulp
- bower дает более широкие возможности по сравнению с установкой из npm, но можно обойтись и без него
bower особенно важен для фронта, т.к. объединяет зависимости одинаковых имён.
Bower — архаизм, но зачастую в npm отсутствует нужный модуль, а ручками копировать и отслеживать не хочется.
Webpack — гибкая и мощная система сборки, однако, в отличие от grunt и gulp, для бэка практически бесполезна, основное — сборка фронта. И нет задач, которые не смог бы решить вебпак (еще бы, у него достаточно мощная система расширений), но, к сожалению, зачастую нужные вещи написаны под грант или галп, а на вебпак переводить слишком накладно. Правда именно так и плодится зоопарк (у меня сейчас галп создает иконичный шрифт из набора svg и запускает регрессионное тестирование, все остальное силами webpack. И если первое — нужно просто посидеть немного, то второе — даже идей нет как впилить, а беглый поиск в гугле ничего внятного не предложил).
Webpack — гибкая и мощная система сборки, однако, в отличие от grunt и gulp, для бэка практически бесполезна, основное — сборка фронта. И нет задач, которые не смог бы решить вебпак (еще бы, у него достаточно мощная система расширений), но, к сожалению, зачастую нужные вещи написаны под грант или галп, а на вебпак переводить слишком накладно. Правда именно так и плодится зоопарк (у меня сейчас галп создает иконичный шрифт из набора svg и запускает регрессионное тестирование, все остальное силами webpack. И если первое — нужно просто посидеть немного, то второе — даже идей нет как впилить, а беглый поиск в гугле ничего внятного не предложил).
(примечание переводчика: или my_class.js, что все-таки популярнее среди программистов, нежели css нотация).
Все же в node.js для именования файлов, по моему субъективному ощущению, чаще используется дефис.
> Only git the important bits
bits — это кусочки. (Но на русский всё равно плохо мантруется, да.)
А по оставлению важных кусочков — мысль более глубокая, если считать, что важные != необходимые.
К примеру, для проекта может быть важно наличие в нём последней рабочей сбоки без необходимости ставить Ноду и запускать сборку. Не нужно держать /node-modules, но полезно — конечную сборку, хотя бы в тестовой папке, или в /dist, и часто — полезно держать /bower-components — сразу есть возможность запустить проект без сборки.
> Попробуйте не соревноваться друг с другом в том, сколько новых технологий можно запихнуть в один проект+1
НЛО прилетело и опубликовало эту надпись здесь
Видимо автор хотел сделать отсылку что в некоторых диалектах США get произносится как gitЭто здесь не причем. «To git smth» образовалось так же, как и «to google smth».
НЛО прилетело и опубликовало эту надпись здесь
Да, обычно говорят "запушь"/"запуши" :)
А как же известное "We will rock you"? Ведь в этой фразе явно не в значении "качать" глагол rock употреблён.
Мне всегда казалось, что в разговорном английском языке норма взять существительное и сделать из него глагол. И даже сомнений не вызвало значение фразы "Only git the important bits", особенно после приведённой расшифровки.
Мне всегда казалось, что в разговорном английском языке норма взять существительное и сделать из него глагол. И даже сомнений не вызвало значение фразы "Only git the important bits", особенно после приведённой расшифровки.
НЛО прилетело и опубликовало эту надпись здесь
Шикарно, вы даже не поленились спросить на StackExchange. :-)
Предлагаю сойтись на том, что это игра слов, понятная тому самому узкому кругу людей, который в основном пользуется Git. Статья ведь тоже очень даже нишевая.
На самом деле, правду знает только автор. Вариант с get тоже не исключён, но я так глубоко не знаю язык, чтобы хотя бы предположить такое.
Предлагаю сойтись на том, что это игра слов, понятная тому самому узкому кругу людей, который в основном пользуется Git. Статья ведь тоже очень даже нишевая.
На самом деле, правду знает только автор. Вариант с get тоже не исключён, но я так глубоко не знаю язык, чтобы хотя бы предположить такое.
my-class.jsЕсли честно, хочется убивать за такое, и особенно за такие советы.
Как я должен догадаться, что экспортируется из этого файла, MyClass, myClass, my_class или вообще myclass? Ну если есть слово class, то еще понятно, а если там (M|m)y(-_)?(T|t)hing? Неужели так трудно сразу назвать файл в нормальном кейсе?
Если мы говорим про NodeJS, то это вообще-то зависит только от вашего личного желания и кодстайла. Вы можете написать:
И здесь как раз наоборот — я сам хочу решать вопрос именования переменных в своем приложении, а не использовать кашу-малашу от авторов разных модулей, которыми я пользуюсь.
const myClass = require('my-class');
const myclass = require('my-class');
const my_class = require('my-class');И здесь как раз наоборот — я сам хочу решать вопрос именования переменных в своем приложении, а не использовать кашу-малашу от авторов разных модулей, которыми я пользуюсь.
Категорически нет. Должен быть единый кодстайл как минимум в наименовании сущностей, и очень плохо, что не все его соблюдают до сих пор.
В идеальном мире да. Но есть одно но — вкусы у всех свои. Кому-то кажется, что классы созданы, чтобы их называли с большой буквы, а кто-то уверен, что это выглядит отвратительно, а третьему вообще нравится перед именем класса ставить $. И все они правы, потому что нет никакого правила, которое говорило бы, как правильно. И не мне это решать и не вам. Вы не заставите всех писать так, как вам нравится. Вы можете соблюдать свой кодстайл в пределах вашего проекта. И именно для этого вам никто не навязывает, как называть классы.
Именно поэтому умные люди придумали PEP8, решив тем самым проблему глобально на уровне языка.
Какбэ нет. Класс для работы с датами называется Date, а не $date или Dat_e или еще что-нибудь. Аналогично с прочими встроенными вещами. PascalCase для классов, camelCase для методов, свойства и функций, UPPER_CASE для констант. Никакого кебаб-кейса или снейк_кейса. Вот чтобы не было разнобоя, надо ориентироваться на это. Ради общего блага. Чтобы не тратить время на идиотские споры, как именовать файлы.
А что вы скажите по поводу объекта Math, который ни разу не класс? Или про константу Math.pi? EcmaScript плохой пример стандарта единым кодстайлом.
Да, согласен, с PI ошибся, но Math все также не кошерно пишется с заглавной буквы.
Пардон, а чем Math не "static class"?
По такой логике любой объект можно назвать статическим классом и писать с большой буквы.
Отчего же? Math содержит ряд математических методов и констант. Этакий namespace по смыслу, helper. Вот, к примеру, document.location это скорее набор полей, отличающихся от страницы к странице.
Правда мне не ясно, почему же тогда crypto, вместо Crypto. При том что Crypto тоже наличиствует, но на мои попытки им как-то воспользоваться ругается illegal constructor. Судя по документации к нему нужно обращаться через window.crypto. Ребята явно чего-то перемудрили.
Правда мне не ясно, почему же тогда crypto, вместо Crypto. При том что Crypto тоже наличиствует, но на мои попытки им как-то воспользоваться ругается illegal constructor. Судя по документации к нему нужно обращаться через window.crypto. Ребята явно чего-то перемудрили.
НЛО прилетело и опубликовало эту надпись здесь
И не мне это решать и не вам
Простите, а кому это решать?
Речь не о том, как надо называть ваши ячейки памяти, а о том, что название файлов под разными ОС ведут себя по разному. Регистро, или не регистрозависимые
Как я должен догадаться, что экспортируется из этого файла
Вы как будто ни одной строчки в node.js не написали.
По умолчанию npm не записывает установленные зависимостиЭто не проблема, если после установки зависимости открывать package.json и вручную вписывать зависимость в него.в package.json (а за зависимостями надо следить всегда!).
Понятно, что это вроде как лишний труд, но его не так много (подумаешь, одну строчку в текстовый файл воткнуть!), а преимуществом такого подхода является контроль над тем, какой диапазон версий зависимости считать приемлемым.
Почему это полезно?
Потому, что для обозначенного подозрения («кто знает, какие в них могут быть баги и проблемы») не существует общего решения, всюду годного пути обхода.
Для одних зависимостей годится предложенное в этой блогозаписи решение (сохранять
Выбор между этими двумя стратегиями лучше делать индивидуально (ориентируясь на возможность разработчиков зависимостей находить и исправлять ошибки, не создавая новых багов и проблем) и делать его именно в момент вписывания зависимости
Кластеризируйте ваше приложениеУ нас в supervisord висит просто nodejs приложений по числу ядер. Использование `process.env.WEB_CONCURRENCY` лучше?
Используйте переменные окружения вместо конфиг файлов.
Почему? Из того, что написано в этом разделе, так и не понял в чём профит, и почему в сообществе nodejs так любят переменные окружения.
мне кажется конфиги в файлах не любят те кто не догадался до require('./config');
Других причин не любить конфиги — не вижу.
Но есть ситуации когда переменные окружения удобнее — например при сборке webpack-ом, которая запускается через npm скриптинг — скажем npm run target, а каждый target выставляет TARGET=blabla webpack… а там уже в конфиге сборки подхватывается.
В общем тут от повара зависит — у каждого свои рецепты.
Других причин не любить конфиги — не вижу.
Но есть ситуации когда переменные окружения удобнее — например при сборке webpack-ом, которая запускается через npm скриптинг — скажем npm run target, а каждый target выставляет TARGET=blabla webpack… а там уже в конфиге сборки подхватывается.
В общем тут от повара зависит — у каждого свои рецепты.
Самое печальное — видеть, как поклонники линуксовой и маковой среды начинают портировать проект на Windows, а у них в package.json ужé полным-полно команд в формате «переменная1=значение1 переменная2=значение2 команда параметры», который в Windows командною строкою не поддерживается в качестве средства пополнения переменных окружения, в котором выполняется команда.
Мрачно подозреваю также, чтоrequire('./config') не нравится тем разработчикам, которых отталкивает чрезмерная строгость языка JSON, а простота формата «переменная=значение» (по сравнению с форматом «"переменная": "значение"», где символов больше, а ошибка в любом из них приводит к неработоспособности) представляется привлекательною.
Немного поразмыслив над этим, я стал сознавать ещё бóльшую привлекательность простого текстового формата конфигураций, в котором и знак равенства не нужен, а простой пробел (или несколько пробелов) отделяет имя переменной от значения:
После этого я пошёл и сочинил модуль для чтения такого формата, потому что готовые модулимне как-то не попадалися для этой цели.
Мрачно подозреваю также, что
Немного поразмыслив над этим, я стал сознавать ещё бóльшую привлекательность простого текстового формата конфигураций, в котором и знак равенства не нужен, а простой пробел (или несколько пробелов) отделяет имя переменной от значения:
# Описание пользователя:
User Mithgol
Karma 60½
ReadOnly No
# Социальные сети:
Fidonet 2:50/88
Twitter FidonetRunesПосле этого я пошёл и сочинил модуль для чтения такого формата, потому что готовые модули
Используйте переменные окружения вместо конфиг файлов
Теперь, чтобы изменить настойки окружения, достаточно создать (и добавить в .gitignore) файл с именем .env
Одного меня что-то в этом смущает? Вместо конфиг-файла у нас теперь есть конфиг-файл и тулза, которая его читает. Нужно больше абстракций, ага.
echo 'node_modules' >> .gitignore
А потом, когда у вас в офисе начал лагать инет, или сам нпм слёг (да, несколько раз бывало и такое), вы сидите и тупо курите бабмук...
Есть кэш, есть sinopia. И есть раздувшийся репозиторий.
сам не делал, но знаю что народ вообще-то свой gitlab разворачивает в локалке и с него тянет модули. И на него же обновляет с github-a. И при форсмажорах чувствует себя в сухе и тепле. Совать модули в проект я вижу только одну причину — пропатченный модуль до момента принятия владельцем пулл-реквеста.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 привычек довольного node.js разработчика