Меню
Что нового?

composer remove

Vano

Новичок
Как удалить расширение, которое мне не нужно? Всмысле, чтобы не оставить мусора. Как когда пытаешся удалить спутник мейл ру) Где что чистить? Я прост не знаю в какие файлы оно че прописывает.
 

Vano

Новичок
А можна удалить с composer.json require расширения и компосер апдейт
 
hell0w0rd

hell0w0rd

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

Absinthe

жожо

Вурдалак

Продвинутый новичок
Absinthe написал(а):
Чтобы обозначить зависимости для работы фреймворка.
Нажмите для раскрытия...
Если ты под фреймворком понимаешь типа symfony/symfony, но наличие composer.lock никакого эффекта не даст. Если ты имеешь в виду symfony-standard, то это спорно, на момент новой установки я обычно хочу последние стабильные версии.
 
Absinthe

Absinthe

жожо
Вурдалак написал(а):
Если ты имеешь в виду symfony-standard, то это спорно,
Нажмите для раскрытия...
ИМХО не спорно. Мою точку зрения разработчики symfony разделяют. Или я разделяю их точку. Протрезвею - точнее скажу.

Вурдалак написал(а):
на момент новой установки я обычно хочу последние стабильные версии.
Нажмите для раскрытия...
composer не может это обеспечить с плавающими зависимостями.
В "стабильной" doctrine/cache 1.4.1 может появиться баг, из-за которого проект будет падать.
Наличие lock-файла это предотвратит.
 
hell0w0rd

hell0w0rd

Продвинутый новичок
Перед composer up прогоняем тесты, после composer up прогоняем тесты. Если что-то поломалось - лочим в composer.json версию, можно же аж до хеша коммита.
Тот факт, что может найтись идиот с *, или ~2, без веской на то причины - это его проблемы.
 
Absinthe

Absinthe

жожо
hell0w0rd написал(а):
Перед composer up прогоняем тесты, после composer up прогоняем тесты. Если что-то поломалось - лочим в composer.json версию, можно же аж до хеша коммита.
Тот факт, что может найтись идиот с *, или ~2, без веской на то причины - это его проблемы.
Нажмите для раскрытия...
Ты сейчас заявляешь, что вы игнорируете возможность использования composer.lock и семантического версионирования, а те, кто научился это использовать - идиоты?
 
fixxxer

fixxxer

К.О.
Партнер клуба
Если брать такую вещь, как application skeleton, то тут может быть два подхода.

1) composer.lock, debian/rhel way: жестко фиксируем все версии, на которых все протестировали (в т.ч. руками) во всех связках. Обновляем лок-файл только для минорных релизов с багфиксами. Получаем стабильность ценой отсутствия новых фич. Подойдет для промышленного производства массы проектов небольшого размера на одном и том же стеке технологий. Если долго на таком сидеть, можно дождаться, что даже багфиксы в эту ветку уже не идут, и огрести на свою голову бэкпортирование.

2) берется последняя версия из ветки, gentoo/arch way. Лок-файла нет. Для публичного app skeleton на гитхабе самое то. Свежак. При существенном покрытии тестами риски небольшие.
 
Absinthe

Absinthe

жожо
Есть еще подход, который, мне кажется, наиболее популярен и задумывался как основной:
composer.json содержит нормальные версии ~2.3, но лок-файл их закрепляет.
Если тесты не пройдут, то просто обновленный lock не попадет в репозиторий.
 
fixxxer

fixxxer

К.О.
Партнер клуба
Для приложений - да. Ну или в варианте 1 для skeleton. В варианте 2 смысла не вижу, опенсорсу для развития нужно тестирование новых версий.
 
Absinthe

Absinthe

жожо
fixxxer написал(а):
Для приложений - да. Ну или в варианте 1 для skeleton. В варианте 2 смысла не вижу, опенсорсу для развития нужно тестирование новых версий.
Нажмите для раскрытия...
Библиотеки могут не только опенсорс быть. Я и закрытые писал.
Да и как-то хочется, чтобы даже опенсорс библиотека работала, а не проверяла какую-то свою зависимость.
 
Войдите или зарегистрируйтесь для ответа.
Сверху