PHPStorm - smart editor tabs?

[MiksIr]

Начни с 10-го сообщения читать, а не с 17-го =)

 

[флоппик]

@MiksIr а ты не путаешь проект в IDE и проект в Гите?
phpStorm нормально обрабатывает vendor, сует его в excluded files, но индексирует, иначе как ты будешь делать автокомплит по коду вне проекта?

 

[MiksIr]

Я не путаю, а вот Absinthe, наверное, путает.
Как буду? Да очень просто - в phpstorm для этого придумали указание include path для внешних библиотек. С миленькой подсветкой открытых файлов этих файлов.
О чем, собственно, и речь тут.

 

[Вурдалак]

А реньше бы спрашивали - что библиотеки делают в проекте. Но нынче "composer way" в головах, куда уж.

Раньше бы имели в виду совсем другое, потому что бы подразумевалось, что 3rd party библиотека под контролем git'а. А сейчас она не под контролем, так что насрать вообще.

 

[MiksIr]

Раньше бы имели в виду совсем другое, потому что бы подразумевалось, что 3rd party библиотека под контролем git'а. А сейчас она не под контролем, так что насрать вообще.

Да ладно, раньше еще и git-а не было. Просто раньше имелось в виду, что библиотека - это то, что может использовать несколько проектов одновременно. Да и сейчас это подразумевается. У меня в работе бывает 10-15 проектов одновременно. И у всех толстый одинаковый вендор. Не круто как-то. Не говоря уже о том, что то же Include Non-project classes выключенное помогает быстрее добираться до своих классов.

 

[AmdY]

В том же composer библиотеки можно устанавливать глобально, так что external libraries очень даже актуальны.

 

[fixxxer]

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

 

[Вурдалак]

У меня в работе бывает 10-15 проектов одновременно. И у всех толстый одинаковый вендор.

Да ты что, прямо-таки одинаковый. Получаешь неявную зависимость между формально несвязанными проектами: обновление vendor'а для одного проекта может затронуть другой. Да нахрен эта экономия нужна.

«Толстый vendor», ога. Да случайно забытый на диске фильм будет больше места занимать, если все твои vendor'ы вместе взятые.

 

[MiksIr]

А что, композер не умеет несколько версий одного пакета? Какой позор...

Не нужно косорукие пакеты ставить, у которых api меняется в минорных версиях. И вообще обновлять пакеты нужно только если очень нужно, а не бездумно. И не в месте дело. А в том, сколько нужно проделать действий, что бы все же этот самый пакет обновить во всех проектах.

 

[Вурдалак]

А что, композер не умеет несколько версий одного пакета?

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

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

Ты сам себя загоняешь в такое положение: имея разные vendor'ы, думать об обновлении других проектов не придётся, потому что это тупо не нужно. Как работали и пусть работают.

 

[MiksIr]

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

Причем тут "один проект". Зациклился ты на "пихаем все в проект". Я о шаред, вообще-то.

Ты сам себя загоняешь в такое положение: имея разные vendor'ы, думать об обновлении других проектов не придётся, потому что это тупо не нужно. Как работали и пусть работают.

О да, пакетописатели у нас святые, багов не делают =)

 

[Вурдалак]

О да, пакетописатели у нас святые, багов не делают =)

А, так ты изменение строчки в composer.json называешь «сколько нужно проделывать действий», а я думал ты про изменение кода.

 

[MiksIr]

В 15 composer.json. И во всех 15 еще обновление запустить и дождаться.
Не, а чо, гики нынче скорее отдельный свой репозиторий пакетов сделают, откуда композер будет ставить все, а потом еще скриптиков понапишут, что бы все разом все ставить, чем задумаются о шаред
Спасибо PHP и композеру, открыл глаза что настоящая сложная разработка - она требует копирования библиотек в проект. И как раньше жили в других системах и языках с шаред библиотеками... ума не приложу.

 

[hell0w0rd]

В 15 composer.json. И во всех 15 еще обновление запустить и дождаться.
Не, а чо, гики нынче скорее отдельный свой репозиторий пакетов сделают, откуда композер будет ставить все, а потом еще скриптиков понапишут, что бы все разом все ставить, чем задумаются о шаред
Спасибо PHP и композеру, открыл глаза что настоящая сложная разработка - она требует копирования библиотек в проект. И как раньше жили в других системах и языках с шаред библиотеками... ума не приложу.

настоящая разработка еще и по виртуалке на каждый проект требует))

 

[Вурдалак]

В 15 composer.json. И во всех 15 еще обновление запустить и дождаться.

Ну да, а потом ещё 15 раскладок. Отдельные проекты же. Любишь на саночках кататься — люби саночки возить. К тому же пример мне кажется высосанным из пальца. Если там не security issue, то наличие бага ещё не означает необходимость обновлять везде, баги разные бывают.

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

 

[AmdY]

настоящая разработка еще и по виртуалке на каждый проект требует))

Suffering-oriented programming

 

[fixxxer]

А что, композер не умеет несколько версий одного пакета? Какой позор...

Не нужно косорукие пакеты ставить, у которых api меняется в минорных версиях

А также не пользоваться косоруким софтом, например, PHP.

 

[MiksIr]

Да ваще, perl 6 наше все.

 

[fixxxer]

И во всех 15 еще обновление запустить и дождаться.

Если чо, можно запустить composer update foo/bar. Это быстро.

Ну и если в 15 проектах одинаковый набор, можно сделать "метапроект", типа acme-libraries, в котором собственно и будет только composer.json.

 

[AmdY]

@fixxxer а как же страдать?
Задачу можно решать разными способами, так что проблема высосана с пальца.