現在、私はいくつかの異なるプロジェクトを持つ会社と協力しており、そのすべてが PHP フレームワークの古いコピーで実行されています。その PHP フレームワークは、サーバー上の共有ディレクトリにインストールされ、PHP のインクルード パスに追加されます。これにより、入力するrequire 'Framework/Lib.phpか何かを入力すると、共有ディレクトリから Lib.php が読み込まれます。フレームワークの独自のコピーを持っているプロジェクトはありません。
これはかなり悪い考えだと思いますが、その理由はよくわかりません（フレームワークを更新できないという主な理由を除いて、古いバージョンを使用して立ち往生しています）。
これには他にマイナスの副作用がありますか、それとも私が思っているほど悪くはありませんか?
これは問題ではありませんし、異常でもありません。
ライブラリまたはフレームワークの複数のコピーが必要な場合は、プロジェクトごとに必要に応じて PHP インクルード パスを独自の php.ini または htaccess ファイルで個別に設定できます。
つまり、今まで通りの作業を続けながら、特定のプロジェクトに必要なライブラリ バージョンを使用できます。
追加の利点は、プロジェクトの 1 つをアップグレードする必要がある場合、htaccess ファイルのインクルード パスを変更するだけで、そのプロジェクトのライブラリ バージョンを変更できることです。ライブラリの追加のコピーをインストールしたり、他のプロジェクトに影響を与えたりする必要はありません。 .
唯一の問題は、フレームワークのコードベースを変更する場合に発生する可能性があります。フレームワークにパッチを適用すると、どのアプリケーションが壊れるか分からないからです。
ただし、フレームワークに依存するすべてのアプリケーションで単体テストを実行している場合は、テストを開始して障害がないかどうかを確認し、最終的に以前の状況に戻すか、十分な自信を持ってテストの失敗を修正できます。
自動テストを行っていないか、アプリのコードベースを変更できない場合は、問題になる可能性があります (繰り返しますが、フレームワーク コードを変更する必要がある場合のみ)。
そこから派生する他の問題は見られません。(小さくて議論の余地のある) 利点でさえあるかもしれません (そのため、誰もが同じバージョンのフレームワークを使用しています)。
また、古いものなので、Composer の依存関係管理について心配する必要はありません。使用していないと思いますよね?