franzliedke / studio

A workbench for developing Composer packages.
MIT License
1.14k stars 73 forks source link

Using studio together with PhpStorm #111

Open windbridges opened 3 years ago

windbridges commented 3 years ago

Hello! Actually I'm not about a bug, but this applies to the simultaneous use of the studio and phpstorm. When I create a symlink to an existing package using studio, it contains a vendor folder with its own dependencies, unlike any other non-local package. That a reason why phpstorm spends a lot of time to index that folder and slows down after, because all nested classes now are duplicated in multiple locations.

I tried to mark project/vendor/me/package/vendor directory as excluded in phpstorm, but it doesn't help ever or helps partially. If I use studio to connect more than one package, work becomes hell, because phpstorm stucks every few seconds.

Has anyone encountered a similar problem and how was it solved?

lkraav commented 3 years ago

Hmm, you should not have dependencies separately installed for your lib. Whole point of composer is to centralize dep mgmt, so it would install everything needed on parent project vendor/.

windbridges commented 3 years ago

Hmm, you should not have dependencies separately installed for your lib. Whole point of composer is to centralize dep mgmt, so it would install everything needed on parent project vendor/.

I will try to explain with an example. Suppose I am developing some package. It has its own dependencies in the vendor directory. In the next step, I decide to create an application that uses this package as a dependency. In order to develop the application and the package at the same time, I execute studio load path/to/my/package before run composer update in the application. After the commands are executed, all the package dependencies appear in the vendor directory, as well as the package itself as a symlink. Of course, since this is a symlink to a local package, it contains its own vendor directory with the same dependencies inside. This is the reason for the duplication of classes and the long indexing process. So, I need the vendor directory to be exist both in the package and in the application in order to be able to develop both projects at the same time.

lkraav commented 3 years ago

So, I need the vendor directory to be exist both in the package and in the application in order to be able to develop both projects at the same time.

No. Like said before, your package should not have it's own runtime vendor/ directory, all package's dependencies need to be in application vendor/.

At the same time, I'm still confused about require-dev dependencies, which could and probably should exist independently of application's. Yet, there's no resolution or response at https://github.com/composer/composer/issues/4522#issuecomment-680993377

Dev dependencies, like linting (PHPCS and friends) are the only reason my package does have its own vendor/ directory, but I consider it a "throwaway" and also never commit package's composer.lock.

windbridges commented 3 years ago

No. Like said before, your package should not have it's own runtime vendor/ directory, all package's dependencies need to be in application vendor/.

Then I'm confused about how you developing the library as separate project without vendor dir? Nothing will work, including unit tests.

apfelbox commented 3 years ago

Yep, that is indeed an issue.

It frequently happens, if you develop your composer package integrated in another package. So imagine you want to develop your Symfony bundle and test it in a real (Symfony-) application. You install everything inside the bundle (as you need the dependencies there for developing / testing / etc..) and you then install the bundle via studio in your project you want to test it in. That is a pretty common use case and triggers this exact issue described here.

There is no real solution yet, unfortunately. For the record, the issue is tracked here on Jetbrains' side: https://youtrack.jetbrains.com/issue/WI-33248