Как можно заменить зависимость на локальную копию? 

CKEditor используется в нашем проекте, и для доработки некоторых функций нам понадобилось изменить несколько родных пакетов, например, <code>@ckeditor/ckeditor5-paragraph</code>. 

Мы создали локальную копию всего пакета в коде нашего проекта, разместив её в <code>src/overrides/ckeditor5-paragraph</code>, и добавили необходимый код в нужные компоненты, так как другого способа реализовать требуемую функциональность не нашлось.

Теперь у меня вопрос: <b>как правильно интегрировать эту модифицированную версию в сборку CKEditor5?</b>

На поверхности лежит довольно простой способ — использовать <code>npm link</code> для замены оригинального модуля на наш модифицированный в <code>node_modules</code>. Это создаст жесткую ссылку, и вместо папки <code>node_modules/@ckeditor/ckeditor5-paragraph</code> будет ссылка на <code>src/overrides/ckeditor5-paragraph</code>. Однако, нужно будет также повторить эту операцию еще 14 раз, так как все пакеты CKEditor имеют свои копии <code>ckeditor5-paragraph</code> в собственных <code>node_modules</code>.

Кроме того, я планирую написать шелл-скрипт, который выполнит <code>npm install</code>, затем серию <code>npm link</code>, и наконец <code>npm run build</code>. 

Я понимаю, что при обновлении версий этот подход может привести к проблемам, так как <code>npm link</code> может перестать работать с устаревшей версией локального пакета, что, вероятно, придется исправить, проверяя все наши изменения. 

Я никогда не сталкивался с подобной задачей - варварской модификации родных модулей используемого пакета. <b>Как это сделать правильно?</b>
  • 1 сентября 2024 г. 14:54
Ответы на вопрос 2 
Модификация библиотек, таких как CKEditor, может быть сложной задачей, особенно если требуется поддерживать локальные изменения. Вот несколько подходов, которые могут помочь вам правильно интегрировать вашу модифицированную версию в сборку CKEditor:

### 1. Замените зависимость путем изменения `package.json`

Вы можете изменить `package.json`, чтобы использовать локальную копию вашего модуля вместо удаленного. Для этого:

1. Убедитесь, что ваш модуль находится в нужном месте, например, `src/overrides/ckeditor5-paragraph`.
2. В корневом `package.json` вашего проекта добавьте путь к модифицированной версии:
   ```json
   {
     "dependencies": {
       "@ckeditor/ckeditor5-paragraph": "file:src/overrides/ckeditor5-paragraph"
     }
   }
   ```

Это укажет npm использовать ваш локальный каталог вместо версии из реестра. Не забудьте выполнить `npm install`, чтобы обновить зависимости.

### 2. Используйте `npm link` для разработки

Как вы уже упомянули, использование `npm link` является одним из подходов, но он может быть громоздким. Если вы все же решите использовать этот способ, можно создать скрипт для автоматизации процесса. Однако, вместо создания жестких ссылок на каждый подмодуль, рассмотрите создание одного общего общего link после установки зависимостей.

### 3. Создание собственного пакета

Если ваши изменения значительные и вы хотите убедиться, что они легко доступны в будущем:

1. Создайте собственный пакет из вашей модифицированной версии CKEditor5. Для этого:
   - Постройте проект CKEditor5 и экспортируйте его как npm-пакет (вы можете использовать `npm pack`).
   - Опубликуйте пакет в вашем локальном реестре (например, используя Verdaccio) или загрузите его локально для разработки.
   - Замените оригинальный пакет на ваш в `package.json`.
   
2. Обеспечьте поддержку версий, поддерживая ваши изменения с последними обновлениями из оригинального репозитория.

### 4. Fork проекта

Форкните репозиторий CKEditor5 на GitHub и внесите необходимые изменения в свою копию. Затем:

1. Настройте ваш проект для использования вашего форка:
   ```json
   {
     "dependencies": {
       "@ckeditor/ckeditor5-paragraph": "git+https://your_repo_url.git"
     }
   }
   ```
2. Это позволит вам иметь полный контроль над библиотекой и применять изменения по мере необходимости.

### 5. Документирование изменений

Независимо от выбранного подхода, убедитесь, что все изменения хорошо задокументированы. Это поможет вам не потерять изменения при обновлениях и упростит процесс работы для других участников команды.

### Заключение

Наиболее предпочтительным вариантом будет использование локального пакета или форка, если ваши изменения достаточно обширны. Это позволяет лучше управлять версиями и уменьшает риск конфликтов с оригинальной библиотекой в будущем. Не забывайте проверять обновления оригинального пакета, чтобы в дальнейшем избегать конфликтов и несоответствий.
В package.json есть раздел overrides как раз для таких модификаций зависимостей зависимостей. В примерах в документации там почему-то акцент сделан только на версии пакетов, но можно и полностью заменить пакет на свой, если указать не версию, а локальный путь к модифицированной версии.
Похожие вопросы
    Показать ещё