Не поставил favicon на сайте — написал статью на хабре
Я бы посоветовал почитать книжки про сетевой стек, поизучать как запросы вообще приходят на сервер, используя протокол HTTP, как можно эти запросы анализировать и делать выводы, а не «Далее идут поиски некорректно работающих яваскриптов, расширений для браузера, но все безрезультатно. Поиск по интернету давал схожие советы. Многие программисты в аналогичной ситуации вводили проверку на уникальность и отсекали дублирующиеся посты.»
Еще в Developer Tools есть замечательная вкладка Network, где можно посмотреть все запросы, которые отправляет браузер
Especially when you start messing with installation folders!
Я могу лишь предположить, что, т.к. речь идет о создании плагина для composer и работы с директорией vendor (т.е. это тесная работа с самим composer), то может возникнуть ситуация, при которой содержимое composer.lock и vendor/composer/installed.json будет не консистентно тому, что на самом деле лежит в vendor. В таком случае composer update не сбросит "поврежденное" состояние.
Это мое предположение, за реальными объяснениями можно обратиться к автору оригинальной статьи.
as it will reset the application and/or plugin state regularly
Все-таки автор оригинальной статьи рекомендует использовать данную комбинацию для сброса состояния приложения, в то время как composer update оперирует текущим состоянием.
Нет, это не так. github.com/composer/composer/blob/1.0.0-beta2/src/Composer/Installer.php#L303
Дальше функции для изучения \Composer\Package\Locker::setLockData, \Composer\Json\JsonFile::write.
composer.lock удаляется только однажды, если выполняется:
`if (empty($lock['packages']) && empty($lock['packages-dev']) && empty($lock['platform']) && empty($lock['platform-dev'])) {`
Тем более не трогается папка vendor.
Собрал здесь немного от себя
Ещё есть goreleaser. Все свои проекты публикую с помощью него. Он умеет и в brew, и в artifactory, и в docker, и ещё во много куда.
На заметку https://dave.cheney.net/2017/04/30/if-a-map-isnt-a-reference-variable-what-is-it
В статье упомянули кастомный URL-роутер, но пример настройки не полный (хотя по тексту дальше используют конкретные профили). Для heap, goroutine,… :
https://github.com/salesagility/SuiteCRM/blob/master/pdf.php
https://github.com/salesagility/SuiteCRM/blob/master/download.php
…
Я бы посоветовал почитать книжки про сетевой стек, поизучать как запросы вообще приходят на сервер, используя протокол HTTP, как можно эти запросы анализировать и делать выводы, а не «Далее идут поиски некорректно работающих яваскриптов, расширений для браузера, но все безрезультатно. Поиск по интернету давал схожие советы. Многие программисты в аналогичной ситуации вводили проверку на уникальность и отсекали дублирующиеся посты.»
Еще в Developer Tools есть замечательная вкладка Network, где можно посмотреть все запросы, которые отправляет браузер
Я могу лишь предположить, что, т.к. речь идет о создании плагина для composer и работы с директорией vendor (т.е. это тесная работа с самим composer), то может возникнуть ситуация, при которой содержимое composer.lock и vendor/composer/installed.json будет не консистентно тому, что на самом деле лежит в vendor. В таком случае composer update не сбросит "поврежденное" состояние.
Это мое предположение, за реальными объяснениями можно обратиться к автору оригинальной статьи.
Все-таки автор оригинальной статьи рекомендует использовать данную комбинацию для сброса состояния приложения, в то время как composer update оперирует текущим состоянием.
github.com/composer/composer/blob/1.0.0-beta2/src/Composer/Installer.php#L303
Дальше функции для изучения \Composer\Package\Locker::setLockData, \Composer\Json\JsonFile::write.
composer.lock удаляется только однажды, если выполняется:
`if (empty($lock['packages']) && empty($lock['packages-dev']) && empty($lock['platform']) && empty($lock['platform-dev'])) {`
Тем более не трогается папка vendor.