1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/mirrors-eggjs

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
CONTRIBUTING.md 22 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 03.03.2025 03:05 38136fe

Английский | Китайский язык (упрощённый)

Руководство по вкладу

Если у вас есть какие-либо замечания или советы, пожалуйста, сообщите о вашей проблеме, или сделайте любые изменения по своему желанию и отправьте PR.

Отчет о новых проблемах

  • Укажите тип проблемы.
  • Перед тем как открыть новую проблему, пожалуйста, проведите поиск по существующим проблемам. Убедитесь, что вы не создаёте дубликат.
  • Ясно объясните цель вашего запроса с помощью меток (см. Полезные метки), заголовка или содержания.

Члены группы Egg проверят цель проблемы, заменят более точными метками, определят связанный этап и назначат разработчиков для её решения. Метки можно разделить на две категории: тип и область.

  • тип: Какой это тип проблемы, например функциональность, ошибка, документация, производительность, поддержка ...
  • область: Что было изменено. Какие файлы были изменены, например core: xx, плагин: xx, зависимости: xx

Полезные метки

  • поддержка: если проблема требует помощи от членов нашей группы, отметьте её как поддержка.
  • ошибка: если вы нашли проблему, которая может быть ошибкой, отметьте её как ошибка. Затем члены нашей группы проверят эту проблему. Если она будет подтверждена как ошибка, эта проблема будет помечена как подтвержденная.
    • Подтвержденная ошибка будет исправлена раньше всего.
    • Если ошибка имеет негативное влияние на работу приложения онлайн, она будет помечена как критическая, что указывает на первостепенную важность, и будет исправлена как можно скорее!
    • Ошибку будут исправлять начиная с самой ранней версии, где это возможно, например, если ошибка должна быть исправлена начиная с версии OnClickListener 0.9.x, то эта проблема будет помечена как 0.9, 0.10, 1.0, 1.1, что указывает на необходимость исправления этой ошибки в этих версиях.
  • core: xx: проблема связана с основной частью, например core: loader указывает на то, что проблема связана с конфигурацией loader.
  • plugin: xx: проблема связана с плагинами, например plugin: session указывает на то, что проблема связана с плагином session.
  • deps: xx: проблема связана с зависимостями, например deps:egg-cors указывает на то, что проблема связана с модулем egg-cors.
  • chore: документация: проблема связана с документацией. Нужно изменить документацию.

Документация

Все новые функции должны быть представлены вместе с документацией. Документация должна удовлетворять нескольким требованиям.

  • Документация должна прояснять одну или несколько аспектов функции, в зависимости от ее природы: что это такое, почему это происходит и как это работает.
  • Лучше всего включить серию процедур для объяснения того, как исправить проблему. Вы также можете предоставить простое, но самоочевидное демонстрационное пример. Все демонстрационные примеры должны быть собраны в репозитории eggjs/examples.
  • Пожалуйста, предоставьте ключевые ссылки, такие как процесс применения, объяснение терминологии и ссылки.

Получение и отправка кода

Получение кода

Пожалуйста, щелкните кнопку "Fork" на главной странице Egg чтобы вилковать последний код в свой собственный репозиторий. Затем клонируйте его на ваш локальный компьютер с помощью помощи git и работайте над этим.

Установка зависимостей

Вы можете установить все зависимости, перечисленные в package.json, с помощью npm:

npm i

Если возникают проблемы, связанные с зависимостями, во время установки, вы можете временно решить их, добавив --legacy-peer-deps, когда ваша версия npm >= 7.X:

npm i --legacy-peer-deps

Затем вы можете отправить PR напрямую в списке "Issues", чтобы своевременно уведомить автора.

Руководство по созданию PR

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

# Создайте новую ветвь для развития. Имя ветви должно быть семантическим, избегая слов типа 'обновление' или 'временная'. Мы рекомендуем использовать название вида feature/xxx, если изменения связаны с реализацией нового функционала.
$ git checkout -b branch-name

# После завершения ваших изменений запустите тест. Добавьте новые случаи тестирования или измените старые, если считаете нужным
$ npm test

# Если ваши изменения прошли тестирование, поздравляем! Пришло время отправить вашу работу обратно. Обратите внимание, что сообщение коммита должно быть записано в следующем формате.
$ git add . # git add -u для удаления файлов
$ git commit -m "fix(role): role.use должен быть xxx"
$ git push origin branch-name

Затем вы можете создать Pull Request на egg

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

  1. Нужно: Какую функцию вы хотите реализовать (обычно, укажите, какая проблема связана).
  2. Причина обновления: В отличие от проблемы. Кратко опишите причину и логику ваших изменений.
  3. Связанные тесты: Кратко опишите, какие части тестирования относятся к вашим изменениям.
  4. Советы пользователям: Предупреждение для пользователей Egg. Вы можете пропустить этот раздел, если PR не связан с обновлением API или потенциальной совместимостью.

Стилевые руководства

Eslint поможет выявить стильные проблемы, которые могут существовать в вашем коде. Ваш код должен успешно пройти тестирование от Eslint. Запустите тест локально командой $ npm run lint.

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

<type>(<scope>): <subject>
<ПУСТАЯ СТРОКА>
<body>
<ПУСТАЯ СТРОКА>
<footer>

(1) Тип

Должен быть одним из следующих:

  • feat: Новая функциональность
  • fix: Исправление ошибки
  • docs: Изменения только в документации
  • style: Изменения, которые не меняют смысл кода (белый пробел, форматирование, отсутствие точки с запятой и т.д.)
  • refactor: Изменение кода, которое ни исправляет ошибку, ни добавляет функциональность
  • perf: Изменение кода, которое повышает производительность
  • test: Добавление недостающих тестов
  • chore: Изменения в процессе сборки или вспомогательных инструментах и библиотеках, таких как генерация документации
  • deps: Обновления о зависимостях

(2) Область

Область может быть любой, указывающей место изменения коммита. Например $location$, $browser$, $compile$, $rootScope$, ngHref, ngClick, ngView`, и т.д.

(3) Тема

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

(4) Тело

Добавьте больше контента в теле, если считаете, что тема недостаточно самоясна, например, что является целью или причиной вашего коммита.

(5) Подвал

  • Если коммит представляет собой разрыв изменений, пожалуйста, укажите это явно здесь.
  • связанные проблемы, например Закрыть #1, Закрыть #2, #3
  • Если есть изменения относительно старого функционала или нового функционала, пожалуйста, ассоциируйте doc и egg-core, например eggjs/egg-core#123

Пример:

fix($compile): [BREAKING_CHANGE] несколько единичных тестов для IE9

Старые IE сериализуют html заглавными буквами, но IE9 нет...
Было бы лучше ожидать регистронезависимость, однако Jasmine не позволяет использовать регулярные выражения для ожиданий выброса.

Документация изменений на eggjs/egg#123

Закрыть #392

BREAKING CHANGE:

  Разрывает foo.bar api, foo.baz следует использовать вместо него

Для получения дополнительной информации просмотрите эти файлы.

Принципы английских переводов

Мы следуем обычным принципам английской статьи при переводе, однако, поскольку существуют некоторые специальные принципы заголовков, мы должны следовать этим правилам:

  • Для существительных, глаголов, местоимений, прилагательных и наречий, первая буква должна быть заглавной. Для предлогов, статей, союзов, междометий и вспомогательных слов, первая буква должна быть строчной. Первая буква первого и последнего слова заголовка всегда должна быть заглавной, вне зависимости от того, что это за слово.
  • Для собственных имён, таких как прямое упоминание переменной или имя плагина, мы должны окружить их обратными кавычками (`) и сохранить их оригинальное значение.
  • Для предлогов длиннее 5 символов, первая буква должна быть заглавной, в противном случае — нет.
  • Для некоторых очень важных заголовков или некоторых постоянных собственных имён, таких как методы HTTP: POST, GET, PUT, DELETE, каждая буква может быть заглавной (ИСПОЛЬЗУЙТЕ С ОСТОРОЖНОСТЬЮ).
  • Если заголовок принадлежит форме О-В (Объект-Глагол) такой как "Управление конфигурациями", лучше перевести его как "Управление Конфигурациями", или "Управляя Конфигурацией" в форме "герундий+существительное".
  • Если ваш заголовок является предложением, пишите его в "Case Sentence" (например: В FAQ каждый заголовок фактически является английским предложением).

Для получения дополнительной информации, пожалуйста, обратитесь к [английскому заголовку Case].

Предварительный просмотр сгенерированных документов

Если вы изменили какой-либо файл внутри папки "docs" внутри папки "site", вам потребуется перегенерировать документы, чтобы увидеть реальное воздействие.

Если вы используете версию Node между 14 и 16, пожалуйста, используйте следующую команду:

$ npm run site:devWithNode14-16

В остальных случаях используйте:

$ npm run site:dev

Node.js не будет работать правильно после версии 17.X из-за проблемы OpenSSL, вам придётся понизить версию Node как решение. Если вы просто хотите построить документы, используйте site:build вместо этого.

Управление выпусками

Egg использует семантическую версию в процессе выпуска на основе semver.

Стратегия ветвей

ветвь master является последней стабильной версией. ветвь next является следующей стабильной версией, находящейся в разработке. Все новые функции будут добавлены в ветку master или next, а также все исправления ошибок, кроме проблем безопасности. Таким образом, мы можем мотивировать разработчиков обновляться до последней стабильной версии. Если какой-либо API будет отключен, это должно быть указано с помощью deprecate в текущей стабильной версии. Старая версия API должна быть совместимой до выпуска следующей стабильной версии. Ветка master не имеет публичного тега. Высокоуровневый фреймворк может работать со стабильными версиями, определёнными с помощью семантической версионной нумерации. Ветка next помечена тегом next. Высокоуровневый фреймворк может использовать egg@next, чтобы тестировать текущую версию в процессе разработки. LTS версии Egg определяются через Milestones. Если версия указана в Milestone, то она является LTS версией. Мы будем исправлять её, если возникнут какие-либо проблемы.

Стратегия выхода

При каждом выпуске стабильной версии будет назначен менеджер проекта (PM), который будет выполнять следующие обязанности на разных этапах выпуска.

Подготовка

  • Установите Milestone. Подтвердите, что запрос связан с Milestone. Назначьте и обновите задачи, как 1.x Milestone.
  • Создайте ветку next из ветки master и отметьте её как next.

Перед выпуском- Подтвердите, что тест производительности пройден и все задачи в текущем Milestone закрыты либо могут быть отложены на более поздние версии.

  • Откройте новый Proposal MR для выпуска и запишите историю как node CHANGELOG. Не забудьте исправить содержание документации, которое относится к выпускаемой версии. Коммиты можно создать автоматически.

    $ npm run commits
  • Назначьте PM для следующей стабильной версии.

Во время выпуска

  • Сохраните стабильную версию (master) на ветку, названную по текущему значению major (например: 1.x), и установите тег release-{v}.x (где v — текущая версия, например release-1.x).
  • Переместите ветку next на master, сделав её последней стабильной версией и удалив тег next, измените содержимое, соответствующее ветке в README.
  • Опубликуйте последнюю стабильную версию на npm, и сообщите предыдущему фреймворку об обновлении.
  • Перед выполнением команды npm publish, прочитайте Как развернуть пакет npm.

Все упомянутые выше теги означают теги npm в package.json.

"publishConfig": {
  "tag": "next"
}

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/mirrors-eggjs.git
git@api.gitlife.ru:oschina-mirror/mirrors-eggjs.git
oschina-mirror
mirrors-eggjs
mirrors-eggjs
master