Нам нужны твои мозги

1. Прочитать issue. Изучить все крайние случаи.
2. Форкнуть Autoprefixer.
3. Изменить data/prefixes.js, использовав данные caniuse-lite/data/features/css-masks.
4. Написать CSS для тестов в test/cases/mask-composite.css и test/cases/mask-composite.out.css. Использовать эти CSS по примеру остальных хаков.
5. Создать lib/hacks/mask-composite.js по примеру других хаков из lib/hacks/.

1. Форкнуть Nano ID.
2. Создать test/bruteforce. Дать ему права на исполнение. Написать в начале #!/usr/bin/env node.
3. Скрипт будет получать имя файла аргументом командной строки: ./test/bruteforce index.js.
4. Дальше скрипт будет читать файл и регулярным выражением находить, где в файле находится алфавит.
5. Дальше скрипт в цикле будет менять порядок; сохранять новый файл на диск; вызывать npx size-limit FILE; парсить полученный размер в ответе Size Limit; запоминать, какой порядок символов дал минимальный размер.
6. В конце скрипт должен записать в файл самый эффективный порядок символов алфавита.

1. Форкнуть Autoprefixer.
2. Добавить тесты.
3. Изучить метод disabled() в Processor — он обеспечивает работу комментария /* autoprefixer: on */.
4. На примере /* autoprefixer: on */ сделать поддержку /* autoprefixer grid: on */ везде, где в Processor используется options.grid.
5. Добавить документацию.

1. Форкнуть Autoprefixer.
2. Добавить тесты.
3. Добавить код предупреждений в Processor.

1. Изучить текущий код.
2. Найти способы сгенерировать SVG на чистом JS.
3. Форкнуть postcss-conic-gradient и исправить его.

1. Форкнуть Autoprefixer.
2. Добавить тесты.
3. Добавить код предупреждений в Processor.

1. Изучить текущий сайт.
2. Изучить, что надо переделать, а что оставить.
3. Придумать дизайн и нарисовать его набросок.
4. Опубликовать набросок вашего дизайна в комментариях к issue.
5. После одобрения дизайна, форкнуть репозиторий и написать новый код.
6. Отправить новый код в pull request.

1. Найти самый полный словарь на npm. Желательно, чтобы там были не только английские слова. Если найти не получается, то можно выложить на npm этот список.
2. Создать новый npm-проект с именем nanoid-good. Не публиковать его, пока Ситник не проверит.
3. Указать nanoid в зависимостях.
4. Сделать index.js, где будет функция, принимающая те же аргументы, что nanoid, но возвращающая ID без обсценных слов.
5. Сделать non-secure.js, где будет такая же логика, как и в index.js, но будет использоваться nanoid/non-secure.

1. Форкнуть yaspeller.
2. Перевести поиск файла настроек на cosmiconfig. На этом этапе искать только файл .yaspellerrc.
3. Добавить тесты на поле "yaspeller" в package.json и добавить поиск его в cosmiconfig.

1. Форкнуть shortid.
2. Поключить в зависимости nanoid.
3. Переписать методы генерации, чтобы он использовал nanoid/generate, вместо собственного алгоритма перестановки алфавита.
4. Проверить, что все старые тесты проходят.

1. Создать новый npm-проект с именем clean-publish.
2. В проекте надо создать исполняемый файл clean-publish.js и прописать его в поле bin в package.json.
3. В пакете будет список ненужных полей из package.json. Например, eslintConfig и jest. Также можно убирать devDependencies и все scripts кроме нужных для npm (например, postinstall).
4. Можно добавить опцию, чтобы указывать дополнительные поля для удаления.
5. Нужно убедиться, что при вызове npm publish его цветной вывод идет в вывод clean-publish.

1. Форкнуть Autoprefixer.
2. Добавить случай в тесты.
3. Исправить код генерации Grid.

1. Форкнуть Autoprefixer.
2. Добавить случай в тесты.
3. Добавить предупреждение, когда такой случай обнаружен.

1. Загрузить бенчмарк.
2. Форкнуть PostCSS.
3. Переключиться на ветку amy в PostCSS.
4. Исправить код токенайзера и парсера.
5. Вызвать gulp build в PostCSS и потом gulp tokenizers в бенчмарке.
6. Вне зависимости от результата отправить PR с результатами бенчмарка.

Сейчас для кода

.grid {
  display: grid;
  grid-template-columns: repeat(2, 1fr);
  grid-template-areas: "a   b"
                       "c   d";
}
@media (min-width: 600px) {
  .grid {
    grid-template-areas: "a   b   c   d";
  }
}
.grid__cell--a {
  grid-area: a;
}

Autoprefixer сгенерирует:

.grid {
  display: -ms-grid;
  display: grid;
  -ms-grid-columns: (1fr)[2];
  grid-template-columns: repeat(2, 1fr);
  grid-template-areas: "a   b"
                       "c   d";
}
@media (min-width: 600px) {
  .grid {
    grid-template-areas: "a   b   c   d";
  }
  .grid__cell--a {
    -ms-grid-row: 1;
    -ms-grid-column: 1;
  }
}
.grid__cell--a {
  -ms-grid-row: 1;
  -ms-grid-column: 1;
  grid-area: a;
}

В итоге, код будет работать неправильно, так как второй .grid__cell--a (вне @media) перезапишет значение первого. Правильный вариант:

.grid {
  display: -ms-grid;
  display: grid;
  -ms-grid-columns: (1fr)[2];
  grid-template-columns: repeat(2, 1fr);
  grid-template-areas: "a   b"
                       "c   d";
}
@media (min-width: 600px) {
  .grid {
    grid-template-areas: "a   b   c   d";
  }
}
.grid__cell--a {
  -ms-grid-row: 1;
  -ms-grid-column: 1;
  grid-area: a;
}
@media (min-width: 600px) {
  .grid__cell--a {
    -ms-grid-row: 1;
    -ms-grid-column: 1;
  }
}

1. Форкнуть Автопрефиксер.
2. Поправить или добавить тесты в файлах в test/cases/grid-template-*.
3. Изменить логику insertAreas.

1. Форкнуть Browserslist.
2. При инициализации node.js найти самый свежий браузер из caniuse-lite. Сравнить время релиза с текущим временем. Вывести предупреждение, если разница больше полугода.
3. Продумать текст предупреждения. По тексту должно быть понятно, что это предупреждение из Browserslist, и должно быть понятно написано, как обновить caniuse-lite (и для npm, и для yarn — в зависимости от наличия yarn.lock рядом с package.json).
4. Добавить тесты.

1. Форкнуть Stylelint.
2. Прочитать, как писать правила для Stylelint.
3. Прочитать про prefers-reduced-motion.
4. Добавить новое правило, которое ищет все селекторы с transition или animation и проверяет, что такой же селектор есть внутри @media (prefers-reduced-motion) { }.
5. Добавить тесты, документацию и все остальное согласно правилам Stylelint.
6. Создать pull request. Внимательно заполнить их шаблон. Не указывать предыдущий issue, раз они обиделись на автора идеи. Расписать по каждому пункту из критериев, почему правило нужно включить в ядро.

1. Форкнуть Stylelint.
2. Прочитать, как писать правила для Stylelint.
3. Добавить новое правило.
4. Учесть и .some:hover { } .some:focus { }, и .some:hover, .some:focus { }.
5. Добавить тесты, документацию и все остальное, согласно правилам Stylelint.
6. Создать pull request. Не указывать предыдущий issue, раз они обиделись на автора идеи. Расписать по каждому пункту из критериев, почему правило нужно включить в ядро.

1. Форкнуть репозиторий сайта.
2. Переключиться в ветку jonathantneal.
3. Подумать, как кратко объяснить, о чем этот плагин, чем он лучше cssnext, чем он может быть полезен разработчикам. Отдельно можно сравнить его с некоторыми функциями Sass и провести ассоциацию с CoffeeScript и Babel.
4. Если есть вопросы по тому, как лучше рассказать о плагине или чем он лучше — спросить в чате PostCSS или лично Ситника.
5. Добавить больше примеров и текста на главную.

1. Форкнуть репозиторий сайта.
2. Подумать, какой логотип взять для postcss-preset-env. Как вариант, можно взять логотип cssdb.
3. Заменить cssnext на postcss-preset-env.
4. Обновить пример. Убрать Custom Properties. Показать использование color-mod() и Custom Media.

1. Изучить ошибку.
2. Форкнуть cssnano.
3. Изучить плагин mergeLonghand.
4. Добавить особую проверку и не удалять дублирующее свойство, если только в одном из свойств используются переменные.

1. Изучить ошибку.
2. Форкнуть cssnano.
3. Изучить плагин mergeRules.
4. Добавить особую проверку и не объединять правила с -ms-input-placeholder в обоих селекторах.

1. Изучить ошибку.
2. Форкнуть cssnano.
3. Изучить плагин mergeLonghand.
4. Изменить логику.

1. Изучить ошибку.
2. Форкнуть cssnano.
3. Изучить плагин mergeRules.
4. Добавить особую проверку и не размещать правила выше all: initial.

1. Изучить ошибку.
2. Форкнуть cssnano.
3. Попробовать повторить ошибку.
4. Исправить ошибку.
5. Желательно добавить тесты, чтобы ошибка не вернулась в будущем.

1. Усатновить yarn.
2. Форкнуть cssnano.
3. Выполнить yarn upgrade-interactive --latest в проекте.
4. Прочитать, что нового для каждого проекта с мажорным обновлениеем (обновлением первого номера версии).
5. Исправить код, если API зависимости изменился.
6. Проверить, что тесты работают.
7. Выполнить yarn upgrade.
8. Проверить, что тесты работают.

1. Форкнуть Autoprefixer.
2. Добавить поддержку комментария для добавления и для удаления правил.
3. Добавить поддержку комментария для добавления и для удаления свойств.
4. Добавить поддержку комментария для добавления и для удаления директив.
5. Добавить тесты.
6. Добавить документацию в раздел Control Comments.

1. Форкнуть Browserslist.
2. Добавить в зависимости node-releases.
3. Добавить поддержку запроса browserslist('node 9.11.1') => ['node 9.11.0'] и тесты для него.
4. Добавить поддержку запроса node 9.11, загружающий node 9.11.1.
5. Добавить поддержку запроса node 9, загружающий node 9.11.1.
6. Добавить поддержку запроса maintained node versions, возращающий все поддерживаемые в данный момент версии.

1. Прочитать о -webkit-print-color-adjust и color-adjust. Узнать, кто их поддерживает и, примерно, с какой версии. Начальные ссылки есть в issue Автопрефиксера.
2. Послать PR в caniuse с данными о префиксах и поддержке разными браузерами. В конце PR написать /cc @ai.
3. Форкнуть Автопрефиксер.
4. Добавить даннные в data/prefixes.js.
5. Добавить новый хак в lib/hacks/. Сделать в нем замену имени свойства по примерам других хаков.
6. Загрузить новый хак в lib/prefixes.js.
7. Добавить тестовые CSS в test/cases/.
8. Добавить тест использующий эти тестовые CSS в test/autoprefixer.test.js.

1. Изучить, как нужно считать вероятность генерации одинаковых ID и количество случайных бит.
2. Сделать статичную страницу, где у пользователя будет спрашиваться длина ID, сколько ID генерируется в час, алфавит. В итоге будет выводиться, как много лет пройдет перед тем, как вероятность получить одинаковый ID в двух документах будет больше, чем 1%.
3. При загрузке страницы эти поля должны быть сразу заполнены какими-то стандартными данными (длина и алфавит по умолчанию для NanoID, 1000 ID в час).
4. Добавить на страницу краткое описание NanoID и описание того, что делает калькулятор.
5. Добавить пример кода: как генерировать ID в NanoID с выбранным алфавитом и длиной. Если алфавит стандартный, нужно использовать require('nanoid'), для нестандартного — require('nanoid/generate').
6. Постараться сделать страницу красиво. Указать межстрочный интервал, выбрать шрифт, выделить главное.

1. Изучить cosmiconfig. Понять, подходит ли он для задачи.
2. Форкнуть size-limit.
3. Исправить ./cli.js для использования с cosmiconfig (или написать код поиска файла настроек самому, если cosmiconfig не подходит).
4. Добавить тесты.
5. Добавить документацию.

1. Форкнуть caniuse-lite.
2. Добавить в src/packer/agents.js копирование release_date из caniuse-db/fulldata-json/data-2.0.json.
3. Добавить тесты в src/agents.test.js.
4. Отправить pull request, упомянув в описании @ai @ben-eb.
5. Форкнуть browserslist.
6. Добавить в QUERIES новый запрос.
7. Добавить тесты на новый запрос.
8. Написать в документации о новом запросе.
9. Отправить pull request.

1. Посмотреть примеры в issue.
2. Почитать документацию по указанным свойствам Grid Layout.
3. Сравнить с документацией на свойства IE/Edge.
4. Форкнуть autoprefixer.
5. Новые сойства добавить в data/prefixes.js, если их там еще нет.
6. В lib/hacks создать/добавить логику изменения синтаксиса.
7. Добавить новые примеры в test/cases/grid.*.

1. Форкнуть emoji-mart.
2. Создать ветку.
3. Установить зависимости с помощью yarn install.
4. Запустить build:example и открыть example/index.html в IE. Убедиться, что всё сейчас работает.
5. Убрать все импорты core-js из проекта.
6. Запустить build:example и открыть example/index.html в IE. Найти ошибки.
7. Переписать проблемные места на ES5. Например, заменив for (item of array) на for (var i = 0; i < array.length; i++).
8. Если перепистаь на ES5 не получается, импортировать только нужные файлы из core-js.
9. Если core-js оказался не нужен, с помощью yarn удалить core-js из зависимостей.
10. Запустить npx size-limit и обновить лимит размера в package.json.

1. Форкнуть emoji-mart.
2. Создать ветку.
3. С помощью yarn удалить webpack и webpack-bundle-analyzer из зависимостей.
4. Переписать задачи build:dist и watch, чтобы они использовали Babel вместо webpack. Можно сразу вызывать babel-cli из package.json или изменить скрипты в scripts/.
5. Изменить main и size-limit в package.json на использование dist/index.js вместо dist/emoji-mart.js.
6. Добавить плагин babel-plugin-transform-react-remove-prop-types.

1. Форкнуть logux-status.
2. Изучить status.js и как он используется в badge.js.
3. Изменить код внутри sync.on('state', …), чтобы connecting передавался в callback не сразу, а только если он не изменилася за 100 мс.
4. Добавить тесты.

1. Форкнуть logux-sync.
2. Изучить документацию по API.
3. Добавить в reconnect.js код, который при событии online пробует подключиться снова.
4. Добавить тесты.

1. Форкнуть logux-core.
2. Добавить опцию keepLast в Log#add().
3. Добавить тесты.

1. Форкнуть yandex-speller.
2. Изучить lib/post.js.
3. В случае ошибки ETIMEDOUT делать еще 2 попытки.

1. Форкнуть logux-core.
2. Сгенерировать документацию — yarn run docs.
3. Изучить API Store из docs/Store.html.
4. Изучить текущие тесты test/memory-store.test.js.
5. Форкнуть logux-client.
6. Изучить текущие тесты test/indexed-store.test.js.
7. Форкнуть logux-store-tests.
8. Создать тесты для всего API Store внутри функции eachTest в index.js по примеру теста is a object.
9. Удалить тест is a object.
10. Подключить ваш форк logux-store-tests в форк logux-core — в package.json можно указывать версию из GitHub.
11. Проверить, что MemoryStore проходит новые тесты. Почистить старые тесты от уже ненужных тестов API.
12. Подключить ваш форк logux-store-tests в форк logux-client.
13. Проверить, что IndexedStore проходит новые тесты. Почистить старые тесты от уже ненужных тестов API.
14. Отправить Pull Request всех трех проектов.

1. Форкнуть logux-server.
2. Изучить, как можно заменять вывод Bunyan на примере bunyan-format.
3. Запустить ./test/__snapshots__/show.js и посмотреть все варианты вывода сервера.
4. Изучить формат Human в reporters/human.
5. Сделать модуль для Bunyan, который брал бы объект текущего bunyan-лога у Logux и выводил его в формате Human. Убедиться, что вывод полностью совпадает с текущим форматом Human.
6. Покрыть этот модуль тестами.
7. Переписать reporters/human, чтобы он использовал новый модуль. Проверить, что старые тесты проходят.

1. Изучить код сайта и понять, где формируется список правил.
2. Форкнуть репозиторий с сайтом. Создать ветку.
3. Добавить на страницу правила ссылку на следующее и предыдущее правило.
4. Добавить JS-код, который будет слушать нажатия на клавиши и переключать страницы по нажатию на стрелки на клавиатуре.

1. Скачать макеты.
2. Изучить макеты Badges.png и Badges usage.svg.
3. Форкнуть logux-status.
4. Добавить badge.js с функцией badge. Она должна принимать Client и объект настроек.
5. Она должна возвращать функцию-отписку, при вызове которой виджет удаляется из DOM.
6. В настройках можно указывать местоположение виджета (в каком углу экрана), стили (Inline Styles) для разных состояний и текст выводимый в виджете.
7. В состоянии synchronized виджет не виден.
8. Если клиент перешёл в состояние disconnected, нужно отобразить «Нет интернета» в виджете.
9. В состоянии wait — добавить «Ваши данные не сохранены».
10. В состоянии connecting и sending нужно показывать «Сохраняю ваши данные», но только если предыдущее состояние было wait.
11. Если мы показывали «Сохраняю ваши данные», то при переходе в synchronized, нужно на пару секунд показать «Ваши данные сохранены».
12. При ошибках wrong-protocol или wrong-subprotocol нужно показывать «Обновите страницу».
13. При любой другой ошибке — обычный красный виджет.
14. В файлах badge/ru.js и badge/en.js нужно указать текст по умолчанию.
15. Стили по умолчанию нужно указать в badge/default.js. SVG-иконки подключать через require('./icon.svg'). Учесть, что стили на странице могут быть любыми, так что лучше сбросить наследуемые свойства.
16. Добавить виджет в test/demo. Результат можно посмотреть, запустив yarn run demo.
17. Добавить модульные тесты на функцию.
18. Добавить документацию в README.md.

1. Изучите Stylelint и выберите пару самых простых настроек.
2. Создайте новый репозиторий.
3. Выберите любой сборщик, JS-фреймворк. Например, webpack и React или Vue.js.
4. Сделайте одностраничный сайт. Справа вопрос — слева файл настроек. Когда пользователь отвечает на вопрос, в настроки добавляется выбранное правило.

1. Форкнуть logux-server.
2. Добавить опцию для смены формата лога.
3. Скопировать reporters/human в reporters/bunyan — заменить код, сохранив API. Общий код можно вынести в reporters/common.js.
4. В server.js загружать разные файлы reporters в зависимости от опции.
5. Покрыть тестами каждый репортер и то, что сервер слушается опции.

1. Форкнуть Browserslist.
2. Придумать, как тестировать ./cli.js. Например, можно его вызывать с помощью spawn().
3. Покрыть тестами.

1. Форкнуть logux-status.
2. Сделать скрипт запуска dev-сервера webpack с одной HTML-страницей.
3. Для нее написать JS-файл, который брал бы Logux Client и подключал бы его к ServerSync через LocalPair.
4. Подключить к клиенту все функции Logux Status.
5. На страницу добавить чекбокс «Connected».
6. На страницу добавить кнопки «Error after 3 seconds» и «Send server error after 3 seconds».
7. На страницу добавить кнопку «Add action to log». Сразу ставить действиям reasons: ['test'] в метадату.
8. На страницу добавить кнопку «Clean actions».
9. Сделать, чтобы JS вставлялся внутрь HTML так, чтобы все было в одном файле.
10. Мы потом выложим эту страницу на GitHub Pages. Так что на ней нужно написать коротко о Logux и о том, что страница тестирует все функции Logux Status. И не забыть поместить логотип Logux, чтобы было красиво.

1. Форкнуть logux-status.
2. Сделать у всех текстов в log.js префикс Logux:.
3. Найти надежный способ определения того, поддерживает ли браузер цветной вывод.
4. Подсветить префикс Logux: фирменным желтым фоном с логотипа Logux.
5. Подсветить жирным node ID, имя состояния и тип action в сообщениях.
6. Добавить во второй аргумент опцию отключения подсветки.
7. Добавить тесты к опции и определению подсветки.
8. Добавить абзац про подсветку в документацию.

1. Форкнуть logux-protocol.
2. Добавить в описание протокола команду ["debug", string type, any data].
3. Форкнуть logux-sync.
4. Добавить в BaseSync метод sendDebug() для отправки команды и событие debug при получении команды.
5. Добавить тесты для новых возможностей.
6. Форкнуть logux-server.
7. Добавить в BaseServer метод debugError(error), который отправит всем клиентам команду debug с типом error и stacktrace.
8. Добавить в Server автоматический вызов debugError при ошибке, если this.env равен development.
9. Добавить тесты на новую логику сервера.
10. Форкнуть logux-client.
11. При получении события debug с ошибкой, выводить ее в консоль, помечая, что это ошибка сервера. Желательно, чтобы ошибка показывалась как обычная JS-ошибка со стандартным UI для stacktrace.
12. Добавить тесты на вывод ошибки.

1. Форкнуть eslint-config-logux.
2. Создать файл node4.js, где подключить node/no-deprecated-api и node/no-unsupported-features (для node.js 4) из eslint-plugin-node.
3. Добавить в node4.js правила, которые обяжут использовать ES6-функции, достпуные в node.js 4.
4. Разделить документацию на инструкции для index.js и для node4.js.

1. Форкнуть logux-status.
2. Добавить log.js с функцией log. Она должна принимать Sync.
3. Она должна возвращать функцию-отписку, при вызове которой логгер перестанет работать.
4. Если был передан не Sync, а объект со свойством sync (например, Logux Client), то брать Sync оттуда.
5. Написать код подписки на connect, state, error и clientError. По этим событиям выводить в консоль браузера, что происходит с Logux.
6. Написать код подписки на add у sync.log. Выводить в консоль информацию о новом событии в логе.
7. Добавить тесты для этой функции.
8. Добавить ее в index.js и добавить тесты на то, что она там есть.
9. Добавить документацию в README.md.

1. Форкнуть logux-server.
2. Сменить настройки ESLint на eslint-config-logux/node4.
3. Обновить синтаксис везде, где ESLint скажет.

1. Форкнуть logux-status.
2. Добавить attention.js с функцией attention. Она должна принимать Sync.
3. Она должна возвращать функцию-отписку, при вызове которой смена <title> перестанет работать.
4. Если был передан не Sync, а объект со свойством sync (например, Logux Client), то брать Sync отткуда.
5. Написать код подписки на событие error и при любом событии, кроме timeout, добавлять к <title> * и убирать ее при открытии вкладки (через Page Visibility API).
6. Добавить тесты для этой функции.
7. Добавить её в index.js и добавить тесты на то, что она там есть.
8. Добавить документацию в README.md.

1. Форкнуть logux-status.
2. Добавить favicon.js с функцией favicon. Она должна принимать Sync и набор ссылок на favicon для обычного состояния, офлайна и ошибки.
3. Она должна возвращать функцию-отписку, при вызове которой смена favicon перестает работать.
4. Если был передан не Sync, а объект со свойством sync (например, Logux Client), то брать Sync отткуда.
5. Написать код подписки на событие state и смену обычный/офлайн favicon.
6. Написать код подписки на событие error и при любом событии, кроме timeout, сменять иконку на иконку ошибки.
7. Добавить тесты для этой функции.
8. Добавить её в index.js и добавить тесты на то, что она там есть.
9. Добавить документацию в README.md.

1. Форкнуть logux-status.
2. Добавить confirm.js с функцией confirm. Она должна принимать Sync и текст предупреждения (с текстом по умолчанию).
3. Она должна возвращать функцию-отписку, по вызове которой предупреждение перестает работать.
4. Если был передан не Sync, а объект со свойством sync (например, Logux Client), нужно брать Sync отткуда.
5. Написать код подписки на событие state, чтобы при наличии неотправленных событий в onbeforeunload предупреждать пользователя, что не все данные успели синхронизироваться.
6. Добавить тесты для этой функции.
7. Добавить ее в index.js и добавить тесты на то, что она там есть.
8. Добавить документацию в README.md.

1. Форкнуть logux-server.
2. Заменить в проекте ws на uws.
3. Проверить все тесты и починить проблемы.

1. Прочитать про снимки Jest.
2. Форкнуть logux-server.
3. Перевести test/server.test.js и test/reporter.test.js на снимки Jest. Файлы test/snapshots/reports.js и test/servers/servers.js можно перенести в тесты — они больше не нужны отдельно.
4. Сделать команду yarn run snapshots, которая вызовет jest -u, а потом выведет снимки в консоль — с ее помощью будет удобно смотреть, что сервер будет выводить в консоль во время работы.

1. Форкнуть logux-server.
2. Добавить в server.js перехват ошибки при вызове метода listen().
3. Найти, как определять ошибки вида «порт занят другой программой» и «у вас нет прав использовать порт меньше 1024».
4. Создать файл error-helper.js, который будет форматировать и выводить подобные ошибки при запуске сервера. Пример можно посмотреть в reporter.js.
5. Написать понятный текст для каждой ошибки — что произошло и как исправить. Текст должен быть понятен начинающему программисту.
6. Добавить тесты.

1. Форкнуть logux-server.
2. Добавить метод options = BaseServer#loadOptions(process, defaults). В нем брать настройки из аргументов --port/-p, --host/-h, --key/-k, --cert/-c и переменных среды LOGUX_PORT, LOGUX_HOST, LOGUX_KEY и LOGUX_CERT.
3. На параметр --help выводить справку по аргументам, переменным среды и завершать работу.
4. Добавить тесты для этого метода.
5. Добавить интеграционное тестирование в test/servers/.
6. Использовать этот метод в app.listen() в примере кода сервера в README.md.
7. Добавить описание аргументов и переменных среды в README.md.

Общее правило в разработке серверов — данные клиента не должны вызвать ошибку и падение сервера. Но сейчас Logux Sync не проверяет входящие сообщения. Например, что в сообщении ["ping"] отсутствует число.

В итоге, ошибка в реализации клиента или действия злоумышленика способны привести к падению сервера. Проблема отягощается отсутствием проверки типов в JS.

Нужно добавить проверку типов в Logux Sync. Желательно не использовать большие библиотеки, так как Logux Sync используется и на клиенте.

1. Изучить возможные сообщения в протоколе Logux.
2. Форкнуть logux-sync.
3. Добавить код проверки. Возможно, имеет смысл вынести его в отдельный файл. При неправильном сообщение возвращать ошибку wrong-format, как это делается в BaseSync#onMessage.
4. Добавить тесты.

Сайт postcss.org написан на Phenomic, специальном React-фреймворке для статичных сайтов.

Но скрипт Gitter — не компонент React, а обычный скрипт. Главный вопрос — где их совместить.

1. Нужно форкнуть postcss.org.
2. Изучить Phenomic и найти место для скрипта Gitter.
3. Отправить pull request.

dart-sass — это официальный парсер Sass, написанный на Dart. Его можно скопилировать в JS, поэтому он уже есть на npm.

Самый надежный способ — взять этот парсер, получить Sass AST и сконвертировать его в PostCSS AST.

1. Изучить dart-sass в поисках API, чтобы отпарсить строку в AST.
2. Если такого API нет, то нужно создать задачу в их репозитории и упоминять там @ai. Если стесняетесь языка — напишите Ситнику, он поможет.
3. Сделать проект postcss-sass и использовать этот API. Пример конвертирования AST можно посмотреть в postcss-csso.

Веб-сокеты практически бессмысленно использовать без шифрования — старые прокси будут резать непонятный им трафик. Использование WebSockets поверх TLS (wss://) решает проблемы со старыми прокси.

Чтобы пользователи потом не жаловались, мы принуждаем их сразу использовать wss:// в продакшене. Но текущая проверка протокола на стороне сервера не очень оправдана — TLS часто реализуется на уровне nginx.

1. Форкнуть logux-client.
2. Выводить подробное предупреждение, если адрес сервера использует ws:// вместо wss:// а домен не равен 127.0.0.1, localhost, ip6-localhost, ::1 и не размещен в зоне .dev.
3. Перед выводом предупреждения проверять, что в браузере есть console.warn.
4. Добавить тесты, создав mock на console.warn.
5. Форкнуть logux-server.
6. Убрать проверку SSL is required in production mode.

Logux не использует Babel. Поскольку часть кода будет работать в старых браузерах, при разработке Logux мы используем ES5.

Есть опасность, что по привычке в код попадет какая-то функция из ES2016 — тесты на Node.js пройдут, а после релиза в Сафари все сломается.

1. Прочитать документацию по разработке плагинов ESLint.
2. Создать проект eslint-plugin-es5. Например, скопировать структуру eslint-plugin-babel.
3. Создать правило по запрету const и let (за основу можно взять правило no-var).
4. Создать правило по запрету стрелочных функций (на основе prefer-arrow-callback).
5. Добавить тесты на оба правила.
6. Выложить проект на npm.
7. Прислать pull request в eslint-config-logux.

1. Нужно форкнуть Browserslist.
2. Найти, где Browserslist ищет и загружает текущий конфиг.
3. На основе этого кода пытаться также найти файл browserslist-stats.json. Учтите, что он может быть выше или ниже, чем обычный файл browserslist.
4. Грузить этот файл той же логикой, что сейчас обрабатывает опцию stats.
5. Если указана опция stats или process.env.BROWSERSLIST_STATS, то искать browserslist-stats.json не нужно.
6. Добавить тесты.
7. Рассказать о новой функции в документации.

Формат package.json ожидается примерно такой:

{
"name": "my-app",
"private": true,
"dependencies": { },
"browserslist": [
 "last 1 version",
 "ie 10"
]
}

1. Нужно форкнуть Browserslist.
2. Найти, где Browserslist ищет и загружает текущий конфиг.
3. Добавить туда поиск и проверку package.json. Этот файл должен также рекурсивно искаться во всех родительских папках.
4. Если в одной и той же папке находится package.json с нужным ключем и browserslist — выкидывать ошибку, так как ситуация потенциально опасная.
5. Добавить тесты на обычный случай и на случай с конфликтом конфигов. Конфиги для тестирования можно разместить в папке test/fixtures.
6. Рассказать о новой функции в документации.

Формат browserslist станет примерно такой:

[development]
last 1 version

[production]
last 2 versions
> 1 %

1. Нужно форкнуть Browserslist.
2. Добавить опцию env в API Browserslist.
3. По умолчанию, ставить env в значение process.env.BROWSERSLIST_ENV, process.env.NODE_ENV или "development".
4. Исправить парсер конфига, чтобы он поддерживал главы вида [name].
5. Если глава не указана, парсить как "defaults".
6. Выбирать список браузеров из конфига в соответствии с env. Если главы, указанной в env, нет, то брать "defaults".
7. Добавить тесты для всех описанных выше случаев.
8. Рассказать о новой функции в документации.

1. Посмотреть, как в плагине уже сделали поддержку PostCSS из синтакса SCSS.
2. Скопировать файл синтаксиса Sass и модифицировать его для SugarSS.
3. Сделать Pull Request.
4. Написать Ситнику свой ник в Твиттере и ВК (если есть) для анонса.

Сейчас каждый плагин PostCSS проходит по AST-дереву CSS каждый раз заново. В итоге нельзя делать вложенные функции, и при большом количестве плагинов сильно проседает производительность.

У Babel есть более правильный visitor API: когда плагины подписываются на какие-то типы узлов. А внутри PostCSS запускается один проход по дереву, который в нужных местах дергает подписанные плагины.

Первый этап:

1. Придумать такой API.
2. Сделать пару примеров псево-кода: как API будет использоваться в простейших плагинах?
3. Отправить эти примеры Андрею (Gist или проект на GitHub).

В качестве примера можно посмотреть на css-minification-benchmark.

1. Нужно создать GitHub-проект.
2. Загрузить через npm самые популярные CSS-минификаторы (можно взять все, что использует css-minification-benchmark).
3. Подобрать известные сайты для тестирования. Нужно взять как хорошие проекты (вроде сайта Github), так и написанные грязно. Еще желательно взять какой-то проект со стилями в опенсорсе.
4. Написать скрипт, который загрузит свежие стили и HTML этих сайтов.
5. Написать скрипт, который который прогонит стили через все минификаторы.
6. Написать скрипт, который запустит тестирование по скриншотами.
7. Написать скрипт, который сгенерирует HTML-страницу с результатами для каждого минификатора.